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Preface 


T he ORACLE Relational Database Management System (RDBMS) 
Version 6.0 is a highly tunable RDBMS. You can enhance database 
performance by adjusting database applications, the database itself, 
and the operating system. Making such adjustments is known as 
tuning. Proper tuning of ORACLE provides the best possible database 
performance for your specific application and hardware configuration. 

This Guide provides the following information: 

• a complete step by step method for tuning ORACLE Version 6.0 
• an explanation of performance diagnostic tools useful in tuning 
the RDBMS 

• installation recommendations for best RDBMS performance 
• additional information on the architecture of the ORACLE 
RDBMS, Version 6.0, as it relates to tuning 
• a list of the 1NIT.ORA parameters useful in tuning the RDBMS 

This Guide supplements the performance tuning information in the 
ORACLE RDBMS Database Administrator’s Guide for Version 6.0. 
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Audience 


How to Use this Guide 


This Guide should be used by individuals responsible for tho rwr^nn 
maintenance, and performance of an ORACLE RDBMS. These 
individuals are usually referred to as Database Administrators , or DBAs. 
However, some of the information in this Guide may also be helpful to 
application designers. Since this Guide presents strategies for tuning 
the RDBMS, database uppfiumuns, ana me operating system, me 
reader should be knowledgeable in each of these areas. The reader 
should also be familiar with the ORACLE RDBMS Database 
Administrator's Guide. 


This Guide is divided into seven chapters and three appendixes: 

Chapter 1 An Overview of Tuning 

This chapter outlines the steps necessary in tuning. It tells you how to 
follow the steps described in subsequent chapters and introduces the 
tuning issues discussed in each step. 

Each of the next four chapters corresponds to a single step in the tuning 
process. Read these chapters for a thorough description of each step. 

Chapter 2 Tuning SQL Statements and Applications 
This chapter helps you write SQL statements so they are processed 
most efficiently by the ORACLE RDBMS. It also shows you how to 
take advantage of ORACLE features designed to improve application 
performance. This chapter covers the following topics: 

• data design 

• the ORACLE optimizer 

• indexes 

• the row-level lock manager 

• PL/SQL 

• the SEQUENCE generator 

• clusters 

• array processing 

This chapter will interest application developers, as well as DBAs. 
Chapter 3 Tuning Memory Allocation 

This chapter helps you allocate memory to ORACLE data structures 
most efficiently. These structures include: 

• context areas 

• the data dictionary cache 

• the buffer cache 
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Chapter 4 Tuning I/O 

This chapter explains how to avoid I/O bottlenecks that can reduce 
performance. In this chapter, you learn to: 

• reduce disk contention 

• allocate space in data blocks 

• avoid dynamic space management 

Chapter 5 Tuning Contention 

This chapter discusses the problems caused by contention and helps 
you recognize when these problems occur. In this chapter, you learn to 
reduce contention for: 

• rollback segments 

• redo log buffer latches 

Chapter 6 Additional Tuning Considerations 

This chapter discusses specific performance-related aspects of the 

RDBMS: 

• sorts 

• free lists 

• checkpoints 

You should complete the tuning steps presented in Chapters 1 through 
5 before considering the issues addressed in this chapter. 

Chapter 7 Performance Diagnostic Tools 

This chapter discusses the following tools that monitor performance: 

• the SQL trace facility 

• the EXPLAIN PLAN statement 

These tools are useful in the tuning process and are referred to in 
Chapters 2 through 6 of this Guide. 

This Guide also contains reference material useful to tuning. Refer to 
the following appendixes for information on these issues. 

Appendix A Initial RDBMS Installation Guidelines 

This appendix discusses installing and configuring the ORACLE 

RDBMS for best performance. 

Appendix B The Database Writer Process (DBWR) 

The Database Writer process (DBWR) is an ORACLE background 
process responsible for the management of the buffer cache. This 
appendix documents the DBWR process. The information in this 
appendix is applicable to ORACLE Version 6.0.27 and subsequent 
releases of ORACLE Version 6.0. 
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Appendix C Changing INIT.ORA Parameters 
This appendix discusses INIT.ORA parameters relevant to 
performance. Tuning your RDBMS may involve modifying these 
parameters. 


Since a large part of this Guide is devoted to the tuning method, many 
database features are discussed only as means of tuning the RDBMS. 
More detailed descriptions of the implementations of thesQ features are 
presented in the ORACLE RDBMS Database Administrator's Guide, Part 
No. 3601-V6.0. Read the material in that guide before proceeding 
further. Chapters relevant to tuning include: 


• Chapter 4 

• Chapter 5 

• Chapter 7 

• Chapter 8 

• Chapter 10 

• Chapter 12 

• Chapter 16 

• Chapter 19 

• Chapter 20 

• Appendix B 

• Appendix D 


Tablespaces and Segments 
User Database Objects 
The Data Dictionary 
ORACLE Memory Structures 
SQL Statement Processing 
Consistency and Concurrency 
Space Management 

Improving Performance of Applications 
Database Tuning 
The SQL*DBA Reference 
The INIT.ORA Parameters 


This Guide discusses the tuning of an ORACLE database that is 
accessed by a single ORACLE instance. Most of the information in this 
Guide also applies to a shared disk database system, or a database 
accessed by multiple instances. Information on shared disk systems 
appears in Chapter 21 "Shared Disk Database Systems" of the ORACLE 
RDBMS Database Administrator's Guide. 


Many tuning features discussed in this Guide are implemented with 
SQL statements. The syntax of all SQL statements is presented in the 
SQL Language Reference Manual, Part No. 778-V6.0. 

Some tuning strategies may involve special features available in 
particular ORACLE application tools, documented in the following 
manuals: 


• SQL*Forms Designer's Reference, Part No. 3304-V3.0 

• PL/SQL User's Guide and Reference, Part No. 800-VI.0 

• Programmer's Guide to the ORACLE Precompilers, 

Part No. 5135-VI.3 
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• Programmer's Guide to the ORACLE Call Interfaces , 

Part No. 5411-V6.0 

• Pro*Ada Precompiler User's Guide , Part No. 606-VI .2 

• Pro*Ada ORACLE Call Interface User's Guide, Part No. 3507-V1.1 

• SQL*Plus User's Guide and Reference , Part No. 5142-V3.0 

. nPACi F RDRM.9 utilities User's Guide^ Part,N q*.3602-V6.0 

Operating system specific tuning issues are discussed in the Installation 
and User's Guide for your operating system. 

The following is a summary of the conventions in this Guide: 

SQL statements SQL statements appear in this font: 


SELECT EMPNO, ENAME FROM EMP 


SQL*Plus 

commands 


SQL*Plus commands appear in the same font as 
SQL statements but they are prefixed by the 
SQL*Plus prompt: 

SQL> SHOW ARRAYSIZE 


SQL*DBA 

commands 


SQL*DBA commands appear in the same font as 
SQL statements, but they are prefixed by the 
SQL*DBA prompt: 


SQLDBA> MONITOR LATCH 


INIT.ORA 

parameters 


Names of INIT.ORA parameters appear in 
uppercase, such as: 

DB_BLOCK_BUFFERS 
LOG_SM ALL_ENTRY_M AX_SIZE 

Names of statistics appear in italics, such as: 


Statistics 


recursive calls 

Timeout Willing to Wait Requests 


Filenames 


Filenames appear in uppercase, such as: 


INIT.ORA 


Chapters, 
appendixes, 
and sections 


Names of parts of ORACLE manuals appear in 
quotes, such as: 


"Performance Diagnostic Tools" 
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Your Comments Are 
Welcome 


We value and appreciate your comments as an ORACLE user and 
reader of the manuals. As we write, revise, and evaluate, your opinions 
are the most important input we receive. At the back of this Guide is a 
Reader 7 s Comment Form which we encourage you to use to tell us 
what you like and dislike about this (or other} OMCUE manuals If 
the form has been used, or you would like to contact us, please use the 
following address, or call us at (415) 506-7000. 

ORACLE RDBMS Product Manager 
Oracle Corporation 
500 Oracle Parkway 
Redwood Shores, CA 94065 
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CHAPTER 

1 



An Overview of 
Tuning 


T he ORACLE RDBMS is a sophisticated and highly tunable 
software product. Its flexibility allows you to make small 
adjustments that affect database performance. By tuning your 
ORACLE RDBMS, you can tailor its performance to best meet your 
needs. 

In this chapter, you will establish your goals for the tuning process. 
After establishing these goals, you can more easily choose the tuning 
measures in this Guide that will most benefit you. 

This chapter also presents an overview of the tuning method 
recommended by Oracle. This method defines a complete, step by step 
process for tuning ORACLE Version 6 . 0 . The overview discusses the 
scope, importance, and benefits of each step of the method. 

If you have not tuned ORACLE Version 6.0 before, you should follow 
the steps of the method in order. This method will provide you with an 
approach to tuning that is both sound and straightforward. It will also 
introduce you to the performance diagnostic tools provided by 
ORACLE. If you are already familiar with tuning ORACLE Version 
6 . 0 , or think you know which part of your RDBMS needs attention, this 
chapter will help you find the specific information you need. 

This chapter also lists some of the most important individual issues to 
consider when tuning ORACLE. These issues highlight the tuning 
process. 
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Setting Goals for Tuning 

Before you begin tuning your ORACLE. RDBMS, you sVou\d establish 

goals for tuning. These goals should stem directly from your reasons 

for tuning. 

Your goals for tuning may include one or more of the following: 

• to improve the performance of a specific type of SQL statement 

• to improve the performance of a specific database application 

• to improve the overall performance of all concurrent users and 
applications on your RDBMS 

Keep your goals in mind as you consider each of the tuning measures 
in this Guide. To decide whether to implement a particular measure, 
you should consider its performance benefits in light of your goals. 

Also keep in mind that your goals may conflict. For example, to 
achieve best performance for a specific SQL statement, you may have to 
sacrifice the performance of other SQL statements running concurrently 
on your RDBMS. 


Steps of the Tuning Method 


The tuning method has four steps. Each step is described in one of the 
next four chapters: 


• Step One: 

• Step Two: 

• Step Three: 

• Step Four: 


Chapter 2 Tuning SQL Statements and Applications 
Chapter 3 Tuning Memory Allocation 
Chapter 4 Tuning I/O 
Chapter 5 Tuning Contention 


These steps are designed to be as modular and independent as possible. 
For example, the benefits of tuning I/O in Step Three are separate from 
the benefits of eliminating contention in Step Four. 


However, decisions you make in one step may influence subsequent 
steps. For example, in Step One you may rewrite some of your SQL 
statements. These SQL statements may have significant bearing on 
parsing and caching issues addressed in Step Two. Also, disk I/O, 
which is tuned in Step Three, depends on the size of the buffer cache, 
which is tuned in Step Two. The steps of the tuning process that have 
the greatest effects on other steps appear early in the method. For this 
reason, you should follow these steps in order. 
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Step One: 
Tuning SQL 
Statements and 
Applications 


Step Two: 
Tuning Memory 
Allocation 


Step Three: 
Tuning I/O 


Before tuning the RDBMS itself, you should be certain that your 
application is taking full advantage of the SQL language and the 
ORACLE features designed to speed application processing. This is the 
goal of Step One. 

Step One involves applying techniques that improve the performance 
of SQL statements and applications. You should use these features 
Udsea on me needs ot your application: 

• data design 

• the ORACLE optimizer 

• indexes 

• the row-level lock manager 

• PL/SQL 

• the SEQUENCE generator 

• clusters 

• array processing 

Appropriate allocation of memory resources to ORACLE memory 
structures can have a large impact on performance. In Step Two, you 
will decide how much memory to allocate to the following structures: 

• context areas 

• the data dictionary cache 

• the buffer cache 

Proper allocation of memory resources can yield these benefits: 

• improved cache performance 

• reduced parsing of SQL statements 

• reduced paging and swapping 


Disk I/O tends to reduce the performance of many software 
applications. However, the ORACLE RDBMS is designed so that its 
performance need not be limited by I/O. 

Tuning I/O involves these procedures: 

• distributing I/O to avoid disk contention 

• storing data in data blocks for best access 

• creating extents large enough for your data 
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Step Four: 

Tuning Contention 


Top Tuning Tips 


Concurrent processing by multiple ORACLE users may create 
contention for ORACLE resources. Contention may cause processes to 
wait until resources are available. In Step Four you will reduce 
contention for: 

• rollback segments 

• redo log buffer latches 

After completing Step Four, reassess your database performance and 
decide whether further tuning is necessary. Since some performance 
gains made in later steps may pave the way for further improvements 
in earlier steps, additional passes through the tuning process may be 
useful. 


Some parts of the tuning process presented in this manual are more 
important than others. The following list highlights the most important 
parts of tuning. This list is by no means an exhaustive collection of all 
the material presented in this Guide. 

Pay particular attention to the issues addressed in this list. If you have 
not tuned ORACLE Version 6.0 before, this list gives you perspective of 
the relative importance of the parts of the tuning process. If you are 
familiar with tuning ORACLE Version 6.0, this list directs you to the 
parts of this Guide that discuss these issues. 

1. Index tables appropriately. Proper use of indexes may improve the 
performance of some SQL statements by orders of magnitude. For 
more information on indexes, refer to Chapter 2 'Tuning SQL 
Statements and Applications." 

2. Take advantage of new ORACLE features in Version 6.0. The 
SEQUENCE generator and the row-level lock manager are both 
discussed in Chapter 2 'Tuning SQL Statements and Applications." 

3. Reduce the time spent parsing SQL statements by keeping dictionary 
data in memory and by keeping frequently used statements parsed 
after execution. For more information on these measures, refer to 
Chapter 3 "Tuning Memory Allocation." 

4. If excessive I/O of ORACLE blocks occurs, increase the size of the 
buffer cache in the System Global Area (SGA). For information on 
resizing ORACLE memory structures, refer to Chapter 3 "Tuning 
Memory Allocation." 
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5. On operating systems with virtual storage, be sure the System Global 
Area (SGA) fits into real memory to ensure fast access to cached 
data. For more information on allocating memory, refer to Chapter 

3 "Tuning Memory Allocation." 

6. Distribute I/O so that none of the disks containing your database files 
and redo log files are operating near full capacity. For more 
information on distributing I/O, refer to Chapter 4 'Tuning L/QC 

7. Reduce contention for latches if the percentage of latch requests that 
result in waiting significantly exceeds 10% or 15%. For methods of 
monitoring and reducing latch contention, refer to Chapter 5 
'Tuning Contention." 

8. Be sure all ORACLE processes, both foreground and background, 
have the same operating system process priority. Performance 
problems may occur if your operating system swaps out a low 
priority process while that process has exclusive access to a 
resource. A high priority process in need of that resource may wait 
indefinitely for the low priority process to be swapped back in. For 
more information on problems caused by contention, refer to 
Chapter 5 'Tuning Contention." 
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CHAPTER 


Tuning SQL 
Statements and 
Applications 


T his chapter presents Step One of the tuning process: tuning SQL 
statements and applications. In this chapter, you will learn to use 
ORACLE database and application features to improve the 
performance of your application. These features include: 

• data design 
• the ORACLE optimizer 
• indexes 

• the row-level lock manager 
• PL/SQL 

• the SEQUENCE generator 
• clusters 
• array processing 

This chapter supplements the application tuning material in Chapter 19 
"Improving Performance of Applications" of the ORACLE RDBMS 
Database Administrator s Guide. Be sure you are familiar with that 
material before proceeding further. 
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Tuning Your SQL Statements and Application 

Tuning your application is an important part of getting the best 
possible performance from your ORACLE RDBMS. You should tune 
your application before tuning the RDBMS itself for these reasons: 

• Application design offers you the most direct control over the 
SQL statements and data processed by the RDBMS. Careful 
application design can help optimize RDBMS performance. 

• Even if you are not familiar with the internal workings of the 
ORACLE RDBMS, you can significantly improve performance 
by tuning your application based on your knowledge of SQL. 

• If your application is not tuned well, it will not run well, even 
on a well-tuned RDBMS. 


Knowing Your Application 

Before implementing the ORACLE features presented in this chapter, 
you should compare the benefits of each feature with the needs of your 
application. To make this comparison, you must be familiar with your 
application, its SQL statements, and its data. 

Consult the individuals responsible for the design of your application. 
Find out what the application does: 

• what SQL statements the application uses 

• what data the application processes 

• what operations the application performs on that data 

Discuss performance with application users. Ask them to identify any 
parts of the application where they feel performance needs 
improvement. Narrow these parts down to individual SQL statements, 
if possible. 

Consult the staff responsible for the performance of your operating 
system on issues specific to operating system tuning. 


Consulting 

Application Designers 
and Users 


2-2 ORACLE RDBMS Performance Tuning Guide 














Using ORACLE Performance Diagnostic Tools 

ORACLE provides several diagnostic tools for observing performance. 
Two of these tools especially helpful in tuning applications are: 

• the SQL trace facility 

• the EXPLAIN PLAN statement 

The SQL Trace Facility Run your application with the SQL trace facility enabled. The SQL 

trace facility generates statistics for each SQL statement processed by 
ORACLE. These statistics reflect: 

• the number of times each SQL statement is parsed, executed, 
and fetched 

• the time necessary to process each SQL statement 

• the memory and disk access associated with each SQL 
statement 

• the number of rows each SQL statement processes 

From these statistics, determine which SQL statements take the most 
time to process. Concentrate your tuning efforts on these statements. 

The EXPLAIN PLAN Use the EXPLAIN PLAN statement in conjunction with the SQL trace 
Statement facility. The EXPLAIN PLAN statement shows the execution plan for 

each SQL statement in your application. The execution plan describes 
the operations carried out by ORACLE to execute a SQL statement. By 
analyzing the execution plan, you can identify inefficient statements in 
your application. Consider tuning these SQL statements also. 

These tools can help you locate particular SQL statements that may 
slow your application. For additional information on how to invoke 
these tools and analyze their output, refer to Chapter 7 "Performance 
Diagnostic Tools." 


Modifying SQL Statements and Applications 

The process of application tuning depends largely on the application 
itself. Some features of the ORACLE RDBMS can potentially improve 
your application's performance. This chapter discusses each of these 
features. 

Each feature benefits performance in its own way. Choose which 
features to employ based on their benefits and your application's needs. 
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Considering Data 
Design 


Considering General 
Performance Features 


Considering Specific 
Performance Features 


Data Design 


Data design is the first step in writing any database application. 
Determining the structure of the tables that contain application data is 
an essential part of designing the application itself. Good data design 
provides: 

• the flexibility to easily modify the application 

• the basis for optimal application performance 

Be sure your data design lends itself to both of these needs. See the 
next section for specific hints on data design. 


Some ORACLE features can improve the performance of nearly every 
application. Understanding these features will help you write optimal 
SQL statements and applications. Be sure you are making the best 
possible use of these features: 

• the ORACLE optimizer 

• indexes 

• the row-level lock manager 


Other ORACLE features improve the performance of specific database 
operations. These features may help the performance of your 
application, depending on the operations it performs: 

• PL/SQL 

• the SEQUENCE generator 

• clusters 

• array processing 


One of the first steps in designing a database application is determining 
the structure of the underlying tables that are to hold the data. 

Although you may store the same data in many different ways, 
choosing a sound relational design has many benefits, not the least of 
which is good database performance. This section tells you: 

• what good data design is 

• what the advantages and disadvantages of different designs are 

• how to determine the best design for your application data 
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Anyone designing a database application for the first time could 
certainly profit from an understanding of relational theory and 
normalization. Though neither of these concepts fall within the scope of 

this Guide, you can find complete discussions of both in most relational 
database texts. 

Choosing Data Design As a general guideline, a relational design that stores no redundant 

data is usually the most appropriate design for most applications. 
Relational design offers you great flexibility in addition to good 
performance for most SQL statements. 

However, if performance is your primary design concern, you may find 
that a less relational design provides better application performance. In 
this case, you should consider the transactions in your application. You 
may want to choose a design that optimizes the transactions your 
application performs most often. Or you may want to choose a design 
that optimizes your most time-critical transactions. 

If you feel the performance of your application is restricted by the 
design of your database tables, you may want to consider restructuring 
your data. Although restructuring data may involve considerable 
modification of your application, you should remember that a 
well-thought-out database design will serve as a good basis for flexible, 
powerful applications and robust database performance. 


The ORACLE Optimizer 

Every SQL statement processed by the ORACLE RDBMS must be 
examined first by the ORACLE optimizer. The ORACLE optimizer 
chooses the execution plan for each SQL statement. The execution plan 
is a list of the steps, or database operations, that the RDBMS must 
perform to execute a SQL statement. The ORACLE optimizer chooses 
an execution plan based on the following criteria: 

• the syntax of the SQL statement 

• the predicates, or conditions, of the WHERE clause of the SQL 
statement 

• the structures and definitions of the database objects named in 
the SQL statement 

• any indexes that exist on these database objects 


Tuning SQL Statements and Applications 2-5 


1 








Example of 
Optimization 


The rules by which the ORACLE optimizer chooses these steps appear 
in Chapter 19 "Improving Performance of Applications" of the ORACLE 
RDBMS Database Administrator's Guide. Refer to these rules as 
guidelines for writing SQL statements that can be processed most 
quickly by the RDBMS. 

Because SQL is such a flexible language, more than one SQL statement 
may meet the needs of your application. Although two SQL statements 
may produce the same result, ORACLE may process one considerably 
faster than the other. In such a case, you should apply the EXPLAIN 
PLAN statement to both SQL statements and compare the execution 
plans to determine which is statement is more efficient. 


This example shows that the syntax you choose for your SQL 
statements can have an impact on how ORACLE executes them. This 
example shows the execution plans for two SQL statements that 
perform the same function. 

Both SQL statements query the EMP and DEPT tables. Both statements 
return all the departments in the DEPT table that have no employees in 
the EMP table. Each statement searches the EMP table with a subquery. 

Assume an index, DEPTNO_INDEX, has been created on the DEPTNO 
column of the EMP table. This index can speed up queries of the EMP 
table. 

This is the first statement and its execution plan produced by the 
EXPLAIN PLAN statement: 

SELECT DNAME, DEPTNO 
FROM DEPT 

WHERE DEPTNO NOT IN 

(SELECT DEPTNO 



FROM EMP) 


OPERATION 

OPTIONS 

OBJECT_NAME 

FILTER 



TABLE ACCESS 

FULL 

DEPT 

TABLE ACCESS 

FULL 

EMP 


The third line of the execution plan indicates that this SQL statement 
performs a full table scan of the EMP table. This full table scan is a 
time-consuming operation. The EMP table is scanned despite the index 
on the DEPTNO column. 
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This index is not used because the subquery that searches the EMP 
table does not have a WHERE clause. In most cases, a SQL statement 
cannot use an index if the indexed column is not named in the 
statement's WHERE clause. 

However, this SQL statement selects the same rows by accessing the 
index: 

SELECT DNAME, DEPTNO 
FROM DEPT 
WHERE NOT EXISTS 

(SELECT DEPTNO 
FROM EMP 

WHERE DEPT.DEPTNO = EMP.DEPTNO) 

OPERATION OPTIONS OBJECT_NAME 

FILTER 

TABLE ACCESS FULL DEPT 

INDEX RANGE SCAN DEPTNO_INDEX 

The WHERE clause of the subquery names the DEPTNO column of the 
EMP table, so the index DEPTNOJNDEX is used. The use of the index 
is reflected in the third line of the execution plan. The index range scan 
of DEPTNOJNDEX takes less time than the full scan of the EMP table 
in the first statement. Furthermore, the first query performs one full 
scan of the EMP table for every DEPTNO in the DEPT table. For these 
reasons, the second SQL statement is faster than the first. 


Indexes 

Indexes are database structures that boost the performance of queries. 
This section explains: 

• what indexes do 

• how indexes improve performance 

• when to use indexes 

• how to choose indexes 

Indexes are used in conjunction with table columns. An index 
associates each distinct value of a column with the rows in the table 
that contain that value. The column that has the index is called the key 
column. 

You can create an index with the CREATE INDEX statement. For 
information on this statement, refer to the SQL Language Reference 
Manual. 


Tuning SQL Statements and Applications 


2-7 










Unique 


indexes 


How Indexes Improve 
Performance 


When to Use Indexes 


Full Table Scans 


Some indexes can be used to enforce uniqueness among the values in a 
column. Such an index is called a unique index. If a unique index is 
created, no two rows in the table may contain the same value in the 
indexed column. 


Indexes can be used to optimize queries. A query that references an 
indexed column in its WHERE clause can use the index. When a query 
uses an index, ORACLE searches the index for all the values that meet 
the condition specified by the WHERE clause. If the query selects only 
the indexed column, the query can read the indexed column values 
directly from the index, rather than from the table. 

For each value, the index also identifies the locations, or ROWIDs, of 
rows in the table having that value. If the query selects data in addition 
to the indexed value, ORACLE finds the rows in the table based on the 
ROWIDs. Searching by ROWID is the fastest way for ORACLE to 
locate a single row. 

Indexes improve the performance of queries that select a small 
percentage of rows from a table. As a general guideline, you should 
use indexes for queries that select less than 10% or 15% of a table's rows. 


If a query does not use an index, ORACLE must perform a full table 
scan to execute the query. A full table scan involves reading all rows of 
a table sequentially. ORACLE examines each row to determine 
whether it meets the criteria of the query's WHERE clause. Finding a 
single row with an indexed query can be considerably faster than 
finding the row with a full table scan. However, a query that selects 
more than 10% or 15% of a table's rows may be performed faster by a 
full table scan than by an indexed query. 

To perform a full table scan, ORACLE reads every block in the table. 

For each block, ORACLE reads every row stored in the block. 

ORACLE reads each block only once. To perform an indexed query, 
ORACLE reads the rows in the order in which they appear in the index, 
regardless of which blocks contain them. If a block contains more than 
one selected row, ORACLE may read that block more than once. In 
some cases, a full table scan many require less I/O than an indexed 
query. 
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Multi-Block Reads 


Choosing Columns to 
Index 


ORACLE can use a multi-block read to read several sequential Stacks 
from disk at once. Since full table scans often read sequential blocks, 
ORACLE often performs full table scans with multi-block reads. 
However, since indexed queries usually read randomly-accessed 
blocks, ORACLE cannot perform indexed queries with multi-block 
reads. ORACLE must read these blocks one at a time. 


The number of blocks read by a multi-block read is determined by the 
INIT.ORA parameter DB_FILE_MULTlBLOCK_READ_COUN . 
your application performs many full table scans on large tables, you 
may improve performance by increasing the value of this parameter. 
Increasing this value increases the number of blocks read by a single 
multi-block read and may reduce the number of multi-block reads 
necessary to read a large table. 


The multi-block read is a new feature of ORACLE Version 6.0. Due to 
multi-block reads, some full table scans may be faster in ORACLE 
Version 6.0 than in previous versions of ORACLE. If you are 
upgrading an application to ORACLE Version 6.0, you should consider 
any indexed queries in your application to determine whether full tab c 
scans might retrieve data faster. 


Follow these guidelines for choosing columns to index: 

• Index columns that are used frequently in WHERE clauses. A 
query that refers to an indexed column in its WHERE clause 
can use the index. 

• Index columns whose maximum and minimum values are 
selected frequently. A query that selects an indexed value 
using the SQL group functions MAX or MIN can use the index. 

• Index columns that are used frequently to join tables in SQL 
statements. For more information on optimizing joins, refer to 
the section "Clusters” later in this chapter. 

• Index columns with high selectivity. Selectivity is high if few 
rows have the same value in the key column. Unique indexes 
are the most selective and the most effective in optimizing 
query performance. 

• Do not index columns with few distinct values. Such columns 
have low selectivity. For example, consider a column 
containing equal numbers of the values YES and NO. Indexing 
such a column would not normally improve performance. 
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Concatenated Indexes 

How Concatenated 
Indexes Improve 
Performance 


• Do not index columns in small tables. If a table uses fewer 
than 5 data blocks, a full table scan may return rows faster than 
an indexed query. You can determine how many data blocks a 
table uses by examining the ROWIDs of the table's rows. For 
example, this query returns the number of blocks used by the 
ACCOUNTS table: 

SELECT COUNT(DISTINCT(SUBSTR(ROWID,1,8)||SUBSTR(ROWID,15,4))) BLOCKS 
FROM ACCOUNTS 

Do not index columns that are frequently modified. UPDATE 

statements that modify indexed columns and INSERT and 
DELETE statements that modify indexed tables take longer 
when they must update indexes than if there were no index. 
Such SQL statements must modify data in indexes as well as 
data in tables. 

When choosing whether to create an index, determine whether the 
performance gain for query statements is worth the performance 
tradeoff for INSERT, UPDATE, and DELETE statements. You may 
want to experiment and compare the processing times of your SQL 
statements with and without indexes. You can measure processing 
time with the SQL trace facility. For information on the SQL trace 
facility, refer to Chapter 7 "Performance Diagnostic Tools." 

An index can be made up of more than one column. Such an index is 
called a concatenated index. 

Concatenated indexes benefit performance by providing: 

• high selectivity 

• additional data storage 

Concatenated indexes are useful in providing selectivity. Sometimes 
two columns with low selectivity can be combined to produce a 
concatenated index with a high selectivity. 

Concatenated indexes can also be used to hold additional data from 
columns that are selected by the query. If a query selects a column that 
is not part of the index, ORACLE must find the ROWID in the index 
and then retrieve the corresponding row from the table. If all the 
selected columns are included in a concatenated index, then the query 
can be satisfied entirely be an index search and avoid access to the table 
altogether. 
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Choosing Columns for 

Cmm&iMm 

The columns that make up a concatenated index are referred to as the 
concatenated key. Whether or not a SQL statement uses a concatenated 
index is determined by the columns contained ° f 

the SQL statement and the order of columns in the CREAT h IN Dt A 
statement. A query can only use a concatenated index if it references a 
leading portion of the index in the WHERE clause. The leading portion 
of a concatenated index refers to the first column or columns specified 
in the CREATE INDEX statement. 

This statement creates a concatenated index on the columns )OB, SAL, 
and DEPTNO in the EMP table: 

CREATE INDEX JOB_SAL_DEPTNO ON EMP(JOB, SAL, DEPTNO) 

This index can be used by these queries: 

SELECT * 

FROM EMP 

WHERE JOB = 'CLERK' 

AND SAL = 800 

AND DEPTNO = 20 

SELECT * 

FROM EMP 

WHERE SAL = 1250 

AND JOB = 'SALESMAN' 

SELECT JOB, SAL 

FROM EMP 

WHERE JOB = 'MANAGER' 

All of these queries use a leading portion of the JOB_SAL_DEPTNO 
index The predicates in the WHERE clause need not name the indexed 
columns in The order specified by the CREATE INDEX statement. Note 
that the second query names the SAL column before the JOB column 
even though JOB is the first column in the index. 

Note that the third query can be satisfied entirely by index access. 

Since all columns referenced by the query (in the SELECT list as well as 
the WHERE clause) are part of the concatenated index, the query does 
not require access to the EMP table. 
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The following query, however, cannot use the index to find rows in the 

EMP table. This query does not contain the first COlUIWt Of the \h 
its WHERE clause: 

SELECT JOB 
FROM EMP 

WHERE SAL = 5000 


Ordering the Columns of 
3 Concatenated Index 


Follow these guidelines for ordering key columns when creatine a 
concatenated index: 


it only one column of the concatenated index is used 

KaSmtr' p,acc ,ha ‘ co,umn ,irst in ,he 


If more than one column is used frequently in WHERE clauses, 
place the most selective column first in the CREATE INDEX 
statement. 


Example of an Indexed 
Query 


This example shows how indexes improve the performance of queries. 
It shows a SQL statement that executes more efficiently when using an 
index. SQL trace facility statistics and the execution plan produced by 
the EXPLAIN PLAN statement illustrate the performance gain 
attributable to the index. For more information on the SQL trace 
facility, refer to Chapter 7 "Performance Diagnostic Tools." 

In the output from the SQL trace facility, pay particular attention to the 
statistics in these columns: 


C P U T he value in this column is the CPU time required 

for each processing step: parse, execute, or fetch. 
This value is expressed in hundredths of seconds. 

e * a P The value in this column is the total elapsed time 

required for each step. This value is expressed in 
hundredths of seconds. 

P h y s The value in this column is the number of data 

blocks read from the database files on disk for each 
step. 
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The SQL statement in this example queries a bank account table. The 
statement selects the balance of a single account: 

SELECT BALANCE 

FROM ACCOUNTS 

WHERE ACCNUM = 49999 

is the name of the bank account table 

is the column containing the account TtOTftta fcfi 
each account 

is the column containing the account balance of 
each account 

If there is no index on the ACC_NUM column, the SQL trace facility 
produces these statistics and this execution plan when the query is 
processed: 

count cpu elap phys cr cur rows 

Parse: 1 43 54 3 0 0 

Execute: 1 12102 0 

Fetch: 1 6176 7934 5883 5883 0 1 

Execution plan: 

TABLE ACCESS (FULL) OF ' ACCOUNTS' 

The execution plan indicates that this SQL statement causes ORACLE 
to perform a full table scan of the ACCOUNTS table. 

The performance of the query can be improved by indexing the 
ACC_NUM column. The index can be created with the SQL statement: 

CREATE UNIQUE INDEX ACC_INDEX ON ACCOUNTS(ACC_NUM) 


where: 

ACCOUNTS 

ACC_NUM 

BALANCE 
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After the index is created, the same SQL statement can be processed 
much faster. These statistics and the execution plan are produce for the 
indexed query: 

count cpu elap phys cr cur rows 


Parse: 1 44 66 3 

Execute: 1 100 

Fetch: 1 2 22 4 

Execution plan: 

TABLE ACCESS (BY ROWID) OF 'ACCOUNTS' 

INDEX (UNIQUE SCAN) OF 'ACC_INDEX' (UNIQUE) 

This execution plan indicates that ORACLE accesses the ACCOUNT 
table by ROWID after scanning the index ACCJNDEX. This execution 
plan is faster than the full table scan. 

The statistics generated by the SQL trace facility reflect the performance 
gain attributed to the index. By comparing the values of the phys 
column for each query, you can see that the full table scan requires 
much more I/O than the indexed query. The fetch step of the full table 
scan reads 5883 blocks, although it returns only one row. The full table 
scan reads every row of the table from disk. However, the indexed 
query reads the index from disk and then reads only the matching row 
in the table. The index and the matching row take up fewer blocks than 
the rows read by the full table scan. 

Since the indexed query requires less I/O, it is processed faster than the 
full table scan. From the values of the cpu and elap columns, you can 
see that the fetch step of the indexed query takes much less time than 
the fetch step of the full table scan. 


17 0 

0 0 0 

4 0 1 


The Row-Level Lock Manager 

The ORACLE RDBMS Version 6.0 with the transaction processing 
option includes a row-level lock manager. This section describes: 

• how the row-level lock manager enhances performance 

• how to take advantage of row-level locking 

• how to monitor locking activity 
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How Row-Level 
Locking Enhances 
Performance 


Taking Advantage of 
Row-Level Locking 


The ORACLE RDBMS Version 6.0 with the transaction processing 
option locks data at the row level, rather than at the table level. 
Row-level locking allows multiple users to access different rows of the 
same table without lock contention. 

The resulting performance gain is substantial. This gain is one of the 
biggest improvements in the ORACLE RDBMS from Version 5.1 to 
Version 6.0, as well as one of the greatest advantages of ORACLE over 

VSV^I 

Applications that benefit the most from row-level locking are those that 
perform online transaction processing , or OLTP. Online transaction 
processing applications are characterized by multiple users 
concurrently modifying different rows of the same tables. 

ORACLE also allows multiple users to read and write to the same row 
concurrently. Readers never wait for writers and writers never wait for 
readers. Contention can only occur when multiple processes try to 
write to the same row concurrently. 


Row-level locking requires no special implementation on the part of the 
application developer. However, you can override default row-level 
locking with table-level locking. Table-level locking reduces the 
benefits of the transaction processing option. 

Table level locks are established explicitly by executing SQL statements 
such as: 

LOCK TABLE EMP IN EXCLUSIVE MODE 
LOCK TABLE DEPT IN SHARE MODE 

If you are upgrading an application to the ORACLE RDBMS Version 
6.0 with the transaction processing option, you should remove such 
statements from your application. If your application relies on 
table-level locking, modify it so that it takes advantage of row-level 
locking instead. Also, if you are designing a new application, you can 
achieve better performance by using default row-level locking rather 
than explicit table-level locking. 

Default locking behavior is controlled by two INIT.ORA parameters, 
SERIALIZABLE and ROW_LOCKING. In the ORACLE RDBMS 
Version 6.0 with the transaction processing option, the default value for 
SERIALIZABLE is FALSE and the default value of ROW_LOCKING is 
ALWAYS. If your ORACLE RDBMS has the transaction processing 
option, be sure that both of these parameters are set to their default 
values. These values establish row-level locking as the default. 
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Monitoring Lock 
Activity 


PL/SQ 


PL/SQL Blocks 
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You can observe locking activity through the SQL*DBA MONITOR 
LOCK display. To view the display, issue the SQL*DBA command: 

SQLDBA> MONITOR LOCK 


With this display, you can observe any lock contention that does occur. 
This display may be helpful in recognizing locking bottlenecks, 
especially if you do no! have Ihe transaction processing option Pov 
more information on the SQL*DBA MONITOR LOCK displav refer tn 
Appendix B The SQL’DBA Reference" of the ORACLE RDBMS 
Database Administrator's Guide. 


PL/SQL is Oracle's procedural language extension to SQL. Using 
PL/SQL in your applications can improve performance. This section 
shows you: 

• what the PL/SQL language contains 

• how PL/SQL is executed 

• how PL/SQL improves performance 

• how to use PL/SQL in your applications 

For complete information on PL/SQL, refer to the PL/SQL User's Guide 
and Reference manual. 


PL/SQL allows you to mix SQL statements with procedural constructs. 
A unit of PL/SQL code is called a PL/SQL block. A PL/SQL block may 
contain any of these SQL statements: 

• Data Manipulation Language (DML) statements 
(INSERT, UPDATE, DELETE, and SELECT) 

• cursor operation statements 

(DECLARE CURSOR, OPEN, FETCH, and CLOSE) 

• transaction processing statements 
(COMMIT, ROLLBACK, and SAVEPOINT) 
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The PL/SQL Engine 


How PL/SQL Improves 
Performance 


A PL/SQL block may also contain any of these procedural constructs: 

• flow of control statements, such as: 

• IF... THEN ... ELSE 

• GOTO 

• EXIT 

• repetition statements, such as: 

• FOR ...LOOP 

• WHILE ...LOOP 

• assignment statements, such as: 

• X := Y + Z 

• BONUS := CURRENT_SALARY * BONUS_MULTIPLIER 

Applications pass PL/SQL blocks to a PL/SQL engine. The PL/SQL 
engine processes PL/SQL blocks. To process a PL/SQL block, the 
PL/SQL engine executes procedural statements and passes SQL 
statements to the SQL statement executor in the ORACLE RDBMS. The 
PL/SQL engine is incorporated into these Oracle products: 

• ORACLE RDBMS Version 6.0 with the transaction processing 
option 

• SQL*Forms Version 3.0 

If you have the ORACLE RDBMS Version 6.0 with the transaction 
processing option, you can use PL/SQL in your applications that use 
these ORACLE application tools: 

• ORACLE Precompilers 

• ORACLE Call Interfaces (OCIs) 

• SQLTlus 

• SQL*DBA 

If you have SQL*Forms Version 3.0, you can use PL/SQL in any of 
your SQL*Forms applications, regardless of whether your ORACLE 
RDBMS has the transaction processing option. 


PL/SQL improves performance by reducing calls from your 
application to the RDBMS. Reducing calls is especially helpful in 
networked environments where calls may incur a large overhead. 
PL/SQL reduces calls in these ways: 
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The PL/SQL Engine in the 
ORACLE RDBMS 


FIGURE 2-1 

PL/SQL Boosts Performance 


The PL/SQL Engine in 
ORACLE Application 
Tools 


• If your ORACLE RDBMS contains the PL/SQL engine, your 
applications can pass multiple SQL statements to the RDBMS 
at once. 

• If you have SQL*Forms Version 3.0 which contains the 
PL/SQL engine, your SQL*Forms applications can perform 
procedural operations without calling the RDBMS. 

PL/SQL allows applications to pass multiple SQL statements to the 
RDBMS at once. A PL/SQL block containing multiple SQL statements 
can be passed to the RDBMS in a single call. Without PL/SQL, 
applications must pass SQL statements one at a time, each with a 
separate call to the RDBMS. Figure 2-1 illustrates how PL/SQL reduces 
network traffic and boosts performance. 



PL/SQL allows applications to perform procedural functions that 
might otherwise require calls to the RDBMS. Since a PL/SQL block can 
contain procedural statements, your application can use the PL/SQL 
engine incorporated into the ORACLE application tool to execute such 
statements. 

For example, SQL*Forms applications often use SQL statements to 
perform data calculations. Processing these SQL statements requires 
calls to the RDBMS. In SQL*Forms Version 3.0, data calculations can be 
performed by passing procedural statements to the PL/SQL engine. In 
this case, PL/SQL helps you avoid calling the RDBMS altogether. 
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Using PL/SQL in Your 

Applications 


Follow these guidelines for using PL/SQL with specific ORACLE 
application tools to improve the performance of your applications; 

ORACLE Pass multiple SQL statements in ORACLE 

Precompilers Precompiler programs to the PDPMS with 

PL/SQL blocks instead of embedded SQL. 


SQLTluS For small procedural tasks, submit PL/SQL 

fomSQUTlus rather than using 
SQL*Report or ORACLE Precompiler programs. 

SQL*Forms Replace multiple trigger steps in SQL*Forms 

applications with single trigger steps containing 
PL/SQL blocks. 


The SEQUENCE Generator 

The SEQUENCE generator is a new feature in ORACLE Version 6.0. It 
can be used to produce sequential values. This section shows you: 

• what the SEQUENCE generator can do 

• how the SEQUENCE generator reduces serialization for 
sequence numbers 

• how access to SEQUENCE numbers can be improved 

In database applications, sequences can serve many purposes, such as: 


• unique identification numbers 

• historical timestamps 

If your application uses unique or sequential values for any of these 
purposes, you should consider producing them with the SEQUENCE 
generator. 


Reducing Serialization Before ORACLE Version 6.0, sequential values could only be produced 
for SEQUENCE programmatically. A new primary key value could be obtained by 

Numbers selecting the most recently produced value and incrementing it. This 

method requires a lock during the transaction and causes multiple 
users to wait for the next value of the primary key. This waiting is 
known as serialization. If you are upgrading an application to ORACLE 
Version 6.0, you should replace such operations with calls to the 
SEQUENCE generator. The SEQUENCE generator eliminates 
serialization and improves the concurrency of your application. 
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Example of a Sequence 


Once defined, a sequence can be made available to mauy USeiS. A 
sequence can be accessed! and fntremencea oy muiupie WIUUVJ 

waiting. The SEQUENCE generator does not w .-lit for,, fr>4nMrHnn ihif 
has incremented a sequence to complete before that sequence can be 
incremented again. 

can access the same sequence 
can create the sequence SEQ1 

CREATE SEQUENCE SEQ1 
INCREMENT BY 10 
START WITH 50 

The first value of SEQ1 is 50. Successive values of SEQ1 increment by 10. 

ELIZABETH can grant access to SEQ1 to two other users with this SQL 
statement: 

GRANT SELECT 
ON SEQ1 

TO CHARLES, DIANA 

ELIZABETH can determine the current value of SEQ1 by using the 
pseudo-column CURRVAL in this query: 

SELECT SEQ1.CURRVAL 
FROM DUAL 

CHARLES can increment SEQ1 using the pseudo-column NEXTVAL. 
This SQL statement inserts a new row into the DEPT table using the 
next value of SEQ1: 

INSERT INTO DEPT(DEPTNO, DNAME, LOC) 

VALUES (SEQ1.NEXTVAL, 'CONSULTING', 'LONDON') 

DIANA can also increment SEQ1 using the pseudo-column NEXTVAL: 

INSERT INTO DEPT(DEPTNO, DNAME, LOC) 

VALUES (SEQ1.NEXTVAL, 'MARKETING', 'MANCHESTER') 

The ORACLE RDBMS processes DIANA'S statement immediately, 
regardless of whether CHARLES has committed his transaction. 
However, if CHARLES subsequently rolls back his transaction, the 
sequence number he used cannot be accessed again. 

For more information on creating and accessing sequences, refer to the 
SQL Language Reference Manual . 


Tbis example sYvows how multiple users 
without serialization. User ELIZABETH 
with the SQL statement 
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Caching SEQUENCE 
Numbers 


The Number of Entries in 
the SEQUENCE Cache 


The Number of Values in 
Each SEQUENCE Cache 
Entry 


Sequence numbers can be kept in the SEQUENCE cache in the System 
Global Area (SGA). Sequence numbers can be accessed more quickly in 
the SEQUENCE cache than they can be read from disk. 

The SEQUENCE cache consists of entries. Each entry can hold many 
SEQUENCE numbers for a single sequence. 

Follow these guidelines for fast access to all SEQUENCE numbers: 

• Be sure the SEQUENCE cache can hold all the sequences used 
concurrently by your applications. 

• Increase the number of values for each sequence held in the 
SEQUENCE cache. 

When an application accesses a sequence in the SEQUENCE cache, the 
sequence numbers are read quickly. However, if an application 
accesses a sequence that is not in the cache, the sequence must be read 
from disk to the cache before the sequence numbers are used. 

If your applications use many sequences concurrently, your 
SEQUENCE cache may not be large enough to hold all the sequences. 

In this case, access to sequence numbers may often require disk reads. 
For fast access to all sequences, be sure your cache has enough entries 
to hold all the sequences used concurrently by your applications. 

The number of entries in the SEQUENCE cache is determined by the 
INIT.ORA parameter SEQUENCE_CACHE_ENTRIES. The default 
value for this parameter is 10 entries. If you have enabled auditing on 
your RDBMS, you should allow 1 cache entry for the sequence used for 
audit session numbers. For information on auditing, refer to Chapter 
17 "Security: Database Access" of the ORACLE RDBMS Database 
Administrator's Guide. 

When a sequence is read into the SEQUENCE cache, sequence values 
are generated and stored in a cache entry. These values can then be 
accessed quickly. The number of sequence values stored in the cache is 
determined by the CACHE parameter in the CREATE SEQUENCE 
statement. The default value for this parameter is 20. 

This CREATE SEQUENCE statement creates the SEQ2 sequence so that 
50 values of the sequence are stored in the SEQUENCE cache: 

CREATE SEQUENCE SEQ2 
CACHE 50 

The first 50 values of SEQ2 can then be read from the cache. When the 
51st value is accessed, the next 50 values will be read from disk. 
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Clusters 


How Clusters Improve 
Performance 


Choosing a high value for CACHE enables you to access more 
successive sequence numbers with fewer reads from disk to the 
SEQUENCE cache. However, in the event of an ORACLE instance 
failure, all sequence values in the cache are lost. 

You can use the NOCACHE option in the CREATE SEQUENCE 
statement to store no values of a particular sequence in the SEQUENCE 
cache. In this case, every access to that sequence requires a disk read. 
Such disk reads slow access to the sequence. This CREATE 
SEQUENCE statement creates the SEQ3 sequence so that its values are 
never stored in the cache: 

CREATE SEQUENCE SEQ3 
NOCACHE 


Clusters are database structures that improve the performance of SQL 
statements that join data from multiple tables. This section shows you: 

• what clusters do 

• how clusters improve performance 

• how to use clusters 

• how clusters store data 

A cluster is made up of a group of tables that have one or more 
columns in common. The common column or columns in clustered 
tables form what is called the cluster key. The cluster key must be 
indexed. This index is called the cluster index. 

You can create a cluster with the CREATE CLUSTER statement. For 
information on this statement, refer to the SQL Language Reference 
Manual. 


Clustered data is stored in a "pre-joined" form. Rows in clustered tables 
having the same cluster key value are stored in the same data blocks. 
Joining clustered tables based on a cluster key value requires reading 
fewer blocks from disk than joining tables that are stored individually. 
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Choosing Clusters 


Ordering Tables in 
Clusters 


Several factors determine how clusters affect the performance of 
various SQL statements. You should consider the performance benefits 
and tradeoffs of clusters when deciding whether to cluster tables: 

• Clusters improve the performance ol SQL Statert\£iVt$ Yftcft]?)>fi\ 
clustered tables on the cluster key. Such statements require 
less I/O than if the tables were stored individually. 

• Clusters also improve the performance of SQL statements that 
query tables based on cluster key values. Since all the rows 
with the same cluster key value are stored in the same blocks, 
such queries require less I/O than if the tables were stored 
individually. You can also take advantage of this feature with 
a cluster consisting of a single table. 

• SQL statements that perform full table scans of only one table 
in a cluster may take longer than if the table were stored 
separately. A full table scan of a clustered table requires access 
to all blocks in the cluster, and a cluster usually takes up more 
blocks than would any single table stored individually. 

• SQL statements that insert rows into clustered tables or update 
values of cluster keys may take longer than inserts or updates 
on single tables. Such statements require overhead for 
maintenance of the cluster key. 

To choose whether to cluster tables, consider the benefits and tradeoffs 
of clusters in light of the needs of your application. For example, you 
may decide to cluster tables that are always accessed by your 
application in join statements. However, you probably should not 
cluster tables if your application only joins them once in a while and 
changes their common column values frequently. You may want to 
experiment and compare processing times with your tables both 
clustered and stored separately. 


The order in which clustered tables are created, loaded, or referenced in 
SQL statements may affect performance. Follow these guidelines for 
ordering clustered tables: 

• Create clustered tables in ascending order of size. The smallest 
table, the table with the fewest rows for each cluster key value, 
should be created first. The largest table, the table with the 
most rows for each cluster key value, should be created last. 

• Load clustered tables in ascending order of size. 

• In SQL statements that join clustered tables, reference the 
tables in the FROM clause in descending order of size. 
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Cluster Space 
Management 


Example of a Clustered 
Join 


ORACLE decides how much space in a block to allocate for each cluster 
key value based on the value of the SIZE parameter In the CREATE 

When y° u choosc thc SIZE parameter value for a 
uuster,you should estimate the Amount rtf c^im *mn/{n/< 

cluster key value and all the rows containing that value. The value of 
this parameter is expressed in bytes. 


For example, if your cluster has an average of 5 rows per cluster key 
value and the rows have an average length of 100 bytes, you might use 
a SIZE parameter value of 600. This estimate allows for space to store 
the rows, the cluster key value, and any additional rows added later. 

The amount of space allocated for a single cluster key value determines 
how many cluster key values are stored in each block. If you omit the 
SIZE parameter from a CREATE CLUSTER statement, ORACLE stores 
one cluster key value per block. 

Choose a value for the SIZE parameter carefully. If your estimate is too 
high, ORACLE may allocate too much space for each cluster key value. 
In this case, space in blocks may be wasted. 

If your estimate is too low, ORACLE may not allocate enough space in 
a single block for each cluster key value. Many blocks may be required 
to store rows with the same cluster key value. In this case, more blocks 
must be read for queries based on the cluster key value. 


This example compares the performance of a SQL statement joining 
two separate tables with the performance of the same statement joining 
the same two tables stored in a cluster. The example shows how 
clusters can improve the performance of joins. 

This SQL statement joins the ACCOUNTS and BRANCH tables on the 
ACC_NUM column: 

SELECT * 

FROM ACCOUNTS, BRANCH 

WHERE ACCOUNTS.ACC_NUM = BRANCH.ACC NUM 
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The index I ACC_NUM has been created on the ACC_NUM column of 
the ACCOUNTS table. These are the SQL trace facility statistics and 
execution plan produced by the EXPLAIN PLAN statement when the 
ACCOUNTS and BRANCH tables are stored individually: 


count 

cpu 

elap 

phys 

cr 

cur 

rows 

Parse: 1 

82 

100 

4 

36 

0 


Execute: 1 

1 

6 

1 

0 

2 

0 

Fetch: 5000 

26416 

42198 

6666 

200040 

0 

9999 

Execution plan: 

NESTED LOOPS 

TABLE ACCESS 

TABLE ACCESS ' 

(FULL) OF ' 
(BY ROWID) 

BRANCH' 

OF 'ACCOUNTS' 





INDEX (RANGE SCAN) OF ' IACC_NUM' (NON-UNIQUE) 


If the ACCOUNTS and BRANCH tables are clustered on the 
ACCJNUM column, the same SQL statement produces different 
statistics and a different execution plan: 



count 

cpu 

elap 

phys 

cr 

cur 

rows 

Parse: 

1 

96 

130 

5 

45 

0 


Execute: 

1 

1 

4 

1 

0 

2 

0 

Fetch: 

5000 

10729 

34486 

5010 

17969 

20 

9999 


Execution plan: 

NESTED LOOPS 

TABLE ACCESS (FULL) OF 'BRANCH' 

TABLE ACCESS (CLUSTER) OF 'ACCOUNT' 

Since the ACCOUNTS and BRANCH tables are clustered in the second 
example, ORACLE can execute the statement more efficiently than the 
non-clustered join. The performance gain attributed to the cluster is 
reflected by the difference in the values in the phys column between the 
fetch steps of the non-clustered join and the clustered join. This statistic 
reflects the number of data blocks that must be read for the fetch step. 
Note that the clustered join reads fewer data blocks than the 
non-clustered join. 

The clustered join is also executed much faster than the non-clustered 
join as reflected by the values in the cpu and elap columns. Note that 
the fetch step for the clustered join takes much less time than the fetch 
step for the non-clustered join. 
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Array Processing 


Array processing can improve performance by reducing the number of 
calls from your application to the RDBMS. Array processing allows 
your application to execute a single SQL statement many times with 
only a single call to the RDBMS. This section tells you: 

• what array processing is 

• how array processing improves performance 

• how large to make your arrays 

how to use array processing in your application 


How Array Processing 
Improves Performance 


Every SQL statement issued by an application is passed by the 
a P P .cation to the RDBMS. To pass a SQL statement to the RDBMS the 
application must make a function call. These function calls incur 
overhead that may reduce performance, especially if the application 
communicates with the RDBMS over a network. 


With array processing, the application can issue a SQL statement many 
times with a single call to the RDBMS. For example, with array 
processing your application can make a single call to execute a SQL 
Jitatement 1°0 times. Without array processing, your application must 
call the RDBMS 100 times, once for each execution. By reducing the 
average overhead for each execution, array processing improves 
performance, especially in networked environments. 


Choosing Array Sizes The performance benefits of array processing depend upon the size of 

the array. By increasing the array size, you can further reduce the 
number of calls to the RDBMS. However, increasing the array size 
beyond a certain point will yield negligible performance gains. As a 
general guideline, use an array size of 100 for best performance. 

For example, suppose an application executes a SQL statement 10,000 
times. Without array processing, the application must call the RDBMS 
10,000 times, once for each execution. However, with array processing 
and an array size of 100, the application must call the RDBMS only 100 
times, once for every 100 executions. In this case, increasing the array 
size to 100 reduces the number of calls by 9,900. 

However, increasing the array size above 100 does not significantly 
improve performance. An array size of 1,000 reduces the number of 
calls to 10. This performance gain is relatively small compared to the 
gain from increasing the array size from 1 to 100. 
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Using Array Processing 
in Your Applications 


Using Array Processing 
with the ORACLE 
Precompilers 


Using Array Processing 
with the ORACLE Call 
Interfaces (OCIs) 


Many ORACLE application tools can take advantage of array 
processing. Some of these tools, such as SQL*Forms, use array 
processing automatically. With other tools > you have some control over 
uuajr pi^n.vodiii£,* 'Ti ivoc ‘tvUf&'lt (ClU&t. 

• ORACLE Precompilers 

• ORACLE Call Interfaces (OCIs) 

• SQL*Plus 

• SQL*Loader 

• the Export and Import utilities 

With the ORACLE Precompilers, you can use array processing to 
execute an embedded SQL statement many times. Consider this 
embedded SQL statement in a Pro*C Precompiler program: 

EXEC SQL INSERT INTO ACCOUNTS (ACC_NUM) VALUES (:acc_no); 

If the variable acc_no is an integer variable, the SQL statement is passed 
to the RDBMS and executed once. ORACLE inserts a single row into 
the ACCOUNTS table. In this row, the ACC_NUM column has the 
value of acc_no. 

However, if acc_no is an integer array variable of length 100, the SQL 
statement is passed to the RDBMS and executed 100 times. ORACLE 
inserts 100 new rows into the ACCOUNTS table. In each row, the 
ACC_NUM column has the value of one of the elements of the acc_no 
array. 

You can also use array processing in an ORACLE Precompiler program 
to fetch many rows with a single FETCH statement. For more 
information on array processing with the ORACLE Precompilers, refer 
to one of these manuals: 

• Programmer's Guide to the ORACLE Precompilers 

• Pro*Ada Precompiler User's Guide 

When using the ORACLE Call Interfaces (OCIs), you can implement 
array processing with these OCI calls: 

OEXN The OEXN call executes a SQL statement multiple 

times. One of the arguments of this call specifies 
the number of times the statement is to be executed. 

OFEN The OFEN call fetches multiple rows returned by a 

SQL query. One of the arguments of this call 
specifies the number of rows to be returned. 
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Using Array Processing 
with SQL*Plus 


Using Array Processing 
with SQL*Loader 


Using Array Processing 
with the Import and 
Export Utilities 


For more information on using array processing with the OCIs, refer to 
one of these manuals: 

• Programmer's Guide to the ORACLE Call Interfaces 

• Pro*Ada ORACLE Call Interface User's Guide 

SQL*Plus uses array processing automatically to return many rows 
from the database at once. However, you can control the number of 
rows returned at a time. 

The SQL'Pfus system variable ARRAYSIZE determines how many 
rows are returned by a single call to the RDBMS. The default value of 
ARRAYSIZE is 20. To see the current value of ARRAYSIZE, enter the 
SQL*Plus command: 

SQL> SHOW ARRAYSIZE 

You can increase the number of rows returned by a single call by 
increasing the value of ARRAYSIZE. For example, to set the value of 
ARRAYSIZE to 100, enter the SQL*Plus command: 

SQL> SET ARRAYSIZE 100 

ARRAYSIZE also determines the number of rows copied in a single 
batch by the SQL*Plus COPY command. For more information on 
SQL*Plus commands, refer to the SQL*Plus User's Guide and Reference 
manual. 

SQL*Loader uses array processing automatically to insert many rows 
into the database at once. However, you can control the number of 
rows inserted at a time. 

The SQL*Loader command line argument ROWS determines how 
many rows are inserted at once. The default value for this argument is 
64. To insert more rows at a time, specify a larger value for ROWS. For 
example, to insert arrays of 100 rows, you might invoke SQL*Loader 
with the command: 

SQLLOAD USERID=BAM/BIM, CONTROL=Cl.CTL, DISCARD=D1.DIS, ROWS=100 

For information on SQL*Loader, refer to the ORACLE RDBMS Utilities 
User's Guide. 

The Import and Export utilities use array processing automatically to 
read and write data to and from the ORACLE RDBMS. However, you 
can control the number of rows processed at a time. 
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If you are using Import or Export with the command-line method, you 
can control the array size by specifying the value of the BUFFER 
keyword. The BUFFER keyword determines the size in bytes of the 
buffer used to process data. The default value of this parameter 
depends upon your operating system. 

To choose a value for BUFFER, determine the size of your rows in 
bytes. Then choose how many rows you want to process at once. Use 
the product of these values for the BUFFER value. For example, if you 
want to import rows that are about 4,096 bytes long, and you want to 
import 100 rows at a time, specify a BUFFER value of 409,600 bytes. 

You might invoke Import with this command: 

IMP USERID=BAM/BIM IGNORE=Y FULL=N TOUSER=BEM BUFFER=409600 

If you are using Import or Export with the interactive method, the 
utility prompts you for the size of the buffer. The size you specify must 
be large enough to hold the largest row. If you specify a value of 0, the 
utility processes only one row at a time. 

For more information on Import and Export, refer to the ORACLE 
RDBMS Utilities User's Guide. 
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CHAPTER 


Tuning Memory 
Allocation 


T his chapter presents Step Two of the tuning process: tuning 

memory allocation. This chapter discusses tuning the performance 
of the following ORACLE memory structures: 

• context areas 
• the data dictionary cache 
• the buffer cache 

The performance of the ORACLE RDBMS can be improved by proper 
sizing of these structures. In this chapter, you will allocate memory to 
these structures to achieve best database performance. 
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The Importance of Memory Allocation 

The ORACLE RDBMS stores information in two places: 


• in memory 

• on disk 

Since memory access is much faster than disk access, it is desirable for 
data requests to be satisfied by access to memory rather than access to 
disk. For best performance, it is advantageous to store as much data as 
possible in memory, rather than on disk. However, memory resources 
on your operating system are likely to be limited. Tuning memory 
allocation involves distributing available memory to ORACLE memory 
structures. 


You should tune memory allocation after following the 
recommendations presented in Chapter 2 ’Tuning SQL Statements and 
Applications,” because the memory requirements of your RDBMS 
depend upon your application. Allocating memory before tuning your 
application may make it necessary to resize some ORACLE memory 
structures to meet the needs of your modified application. 

Also, you should tune memory allocation before considering the 
information in Chapter 4 "Tuning I/O.” Allocating memory establishes 
the amount of I/O necessary for RDBMS operation. This chapter 
shows you how to allocate memory in order to perform as little I/O as 
possible. Chapter 4 shows you how to perform that I/O as efficiently 
as possible. 
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ORACLE Memory Structures 

This section introduces the following ORACLE memory structures 



important to tuning: 

• context areas 

• the System Global Area (SGA) 

• caches 

These structures are related by their common need for memory. 
Increasing the size of any one of these structures can potentially 
improve performance. Each of these structures is discussed in detail 
later in this chapter. 

Context Areas 

A context area is a location in memory that holds information necessary 
to process a SQL statement. Every SQL statement processed by the 
RDBMS requires a context area. 

Some ORACLE application tools allow you to control how context 
areas are assigned to the SQL statements in your application. Using 
this control, you may be able to reduce the processing times of your 
SQL statements. 

The System Global 
Area (SGA) 

The System Global Area , or SGA, is a special ORACLE memory structure 
that holds data frequently accessed by ORACLE processes. Since the 
data in the SGA must be readable by all ORACLE processes, the SGA 
resides in shared memory. 

You can see how much memory is allocated to the SGA and each of its 
internal structures by issuing the SQL*DBA command: 

SQLDBA> SHOW SGA 

The output of this command might look like this: 

Total System Global Area 431384 bytes 

Fixed Size 18236 bytes 

Variable Size 339420 bytes 

Database Buffers 65536 bytes 

Redo Buffers 8192 bytes 
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Caches 


Data in the SGA is kept in caches. A cache is a memory location that 
holds copies of data also stored on disk. Data stored in a cache can be 
accessed quickly through memory reads and writes, rather than 
through disk I/O. 

The SGA contains several caches. Each cache holds a different type of 
data. Among these caches are: 

• the data dictionary cache 

• the buffer cache 

When an ORACLE user process accesses data stored in a cache, that 
data can be read directly from memory. This is called a cache hit. When 
a user process needs data that is not in the cache, the process copies the 
data from a database file to the cache before accessing it. This is called 
a cache miss. Data access through cache hits is obviously faster than 
data access through cache misses. 

The size of the cache affects the likelihood that a request for data will 
result in a cache hit. If the cache is large, it is more likely to contain the 
data that is requested. By increasing the size of a cache, you can 
increase the percentage of data requests that result in cache hits. 
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Steps for Tuning Memory Allocation 

This section outlines the process of tuning memory allocation. For best 
results, you should follow these steps in the order they are presented. 
Each step is described in more detail in the remainder of this chapter. 


Tuning Your 
Operating System 


Ensuring that your operating system runs smoothly and efficiently 
establishes a solid basis for allocating memory to the ORACLE RDBMS. 
This step also gives you a good idea of the amount of how much 
memory on your operating system is available for ORACLE. 


Tuning Parsing and The use of context areas and the frequency of parsing are primarily 
Context Areas determined by your application. Parsing affects the frequency of access 

to the data dictionary. Therefore, you should tune context areas before 
tuning the data dictionary cache. 


Tuning the Data Tuning the data dictionary cache is a simple but important step in the 

Dictionary Cache process of memory allocation. The data dictionary cache requires a 

small amount of memory compared to the buffer cache. However, a 
data dictionary cache miss is more expensive than a buffer cache miss. 
Therefore, sufficient memory should be allocated to the dictionary 
cache first. 


Tuning the Buffer After tuning context areas and the data dictionary cache, you can 

Cache devote the remaining available memory to the buffer cache. 

It may be necessary to repeat the steps of memory allocation after the 
initial pass through the process. Subsequent passes will allow you to 
make adjustments in earlier steps based on changes in later steps. For 
example, if you increase the size of the buffer cache, you may need to 
allocate more memory to ORACLE to avoid paging and swapping. 
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Tuning Your Operating System 


Reducing Paging and 
Swapping 


You should begin tuning memory allocation by tun\M yOUT 0tml\I\2 
system with (fiese guafs: 

• to reduce paging and swapping 

• to fit the System Global Area (SGA) into main memory 

• to allocate enough memory to individual users 

These goals apply in general to most operating systems. However, the 
details of tuning your operating system depend on the operating 
system itself. For details on tuning ORACLE on your operating system, 
refer to the Installation and User's Guide for your operating system. 


Your operating system may store information in any of these places: 

• real memory 

• virtual memory 

• expanded storage 

• disk 

Your operating system may also move information from one storage 
location to another. Depending on your operating system, this 
movement is called paging or swapping. Many operating systems page 
and swap to accommodate large amounts of information that do not fit 
into real memory. However, paging and swapping take time. 

Excessive paging or swapping can reduce the performance of your 
operating system. 

Operating system behavior should be monitored with operating system 
utilities. Excessive paging or swapping indicates that new information 
is often being moved into memory. In this case, your system's total 
memory may not be large enough to hold everything for which you 
have allocated memory. You should either increase the total memory 
on your system or decrease the amount of memory you have allocated. 


Tuning the System Since the purpose of the System Global Area (SGA) is to store data in 

Global Area (SGA) memory for fast access, the SGA should always be contained in main 

memory. If the SGA is swapped to disk, its data is no longer so quickly 
accessible. You should ensure that the entire SGA always fits into 
memory and is not paged or swapped. 
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User Memory 
Allocation 


On some operating systems, you may have control over the amount of 
physical memory allocated to each user. Be sure all users are allocated 
enough memory to accommodate the resources they need to use their 
application with the RDBMS. Depending on your operating system, 
these resources may include: 

• the ORACLE executable image 

• the SGA 

• ORACLE application tools 

• application-specific data 

On some operating systems, ORACLE software can be installed so that 
a single executable image can be shared by many users. By sharing 
executable images among users, you can reduce the amount of memory 
required by each user. 


Eliminating Unnecessary Parsing 

In this section you learn how to eliminate unnecessary parsing of SQL 
statements. Controlling parsing involves allocating memory for 
context areas. This section discusses: 

• what parsing is 

• how parsing and context areas are related 

• how to recognize unnecessary parsing 

• how to allocate memory for context areas 


What Is Parsing? Parsing is one step in the processing of a SQL statement by the 

ORACLE RDBMS. Every SQL statement processed by ORACLE must 
be parsed before its first execution. When a SQL statement is parsed: 

• ORACLE checks the statement for syntactic and semantic 
validity. 

• ORACLE determines whether the process issuing the 
statement has privileges to access the database objects 
referenced in the statement. 

• The ORACLE optimizer chooses an execution plan for the 
statement. 

Once a SQL statement has been parsed, it can be executed repeatedly 
without being reparsed. Since parsing is expensive relative to 
execution, it is desirable to parse a SQL statement as seldom as possible. 
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Context Areas and 
Cursors 


Identifying 
Unnecessary Parsing 


The processing of a SQL statement requires space in memory. When a 
statement is parsed, information necessary for its execution is loaded 
into a context area. A context area is a workspace in memory that is 
used for the processing of a SQL statement. A cursor is the name 
identifying a context area. 

Memory allocation for context areas is determined by the three 
INIT.ORA parameters: 

OPEN_CURSORS This parameter determines the total number of 
context areas a single process can have at once. 

The default value is 50. 

CONTEXT_ARE A This parameter determines the initial size of a 
context area. The default value is 4096 bytes. 

CONTEXT_INCR This parameter determines the increment of space 
ORACLE adds to a context area if the cursor 
information exceeds CONTEXT_AREA. ORACLE 
continues to increment the size of a context area by 
CONTEXT_INCR until it is large enough to hold 
all of the cursor information. The default value for 
this parameter is 4096 bytes. 

After a SQL statement is parsed, it can be executed repeatedly, as long 
as its cursor information remains in the context area. However, if a 
different SQL statement is loaded into the context area, the previous 
SQL statement must be reparsed and reassigned to a new context area 
to be executed again. 


You can use the SQL trace facility to determine how many times each 
SQL statement in your application is parsed. Run your application 
with the SQL trace facility enabled and examine the statistics produced 
The count column tells you how many times each statement is parsed, 
executed, and fetched. For information on the SQL trace facility, refer 
to Chapter 7 "Performance Diagnostic Tools." 
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Reducing Parsing 


Reducing Parsing with the 
ORACLE Precompilers 


Reducing Parsing with the 
ORACLE Call Interfaces 
(OCIs) 


If any SQL statements in your application are parsed repeatedly, try to 
reduce the excess parsing. You may have control of parsing frequency 
within your application. The implementation of this control is specific 
to each ORACLE application tool. 

With the ORACLE Precompilers, you control context areas and parsing 
with these options: 

• HOLD_CURSOR 

. RELEASE_CURSOR 

• MAXOPENCURSORS 

These options can be specified in two ways: 

• on the precompiler command line 

• within the precompiler program 

With these options, you can employ different context area management 
strategies during the course of the program. For more information on 
these options, refer to one of these manuals: 

• Programmer's Guide to the ORACLE Precompilers 

• Pro*Ada Precompiler User's Guide 

With the ORACLE Call Interfaces (OCIs), you have complete control 
over parsing and context areas with these OCI calls: 

OOPEN The OOPEN call establishes a cursor and context 

area. 

OSQL3 The OSQL3 call parses a SQL statement into a 

context area. 

For more information on these calls, refer to one of these manuals: 

• Programmer's Guide to the ORACLE Call Interfaces 

• Pro*Ada ORACLE Call Interface User's Guide 
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Reducing Parsing with 
SQL*Forms 


Allocating Context 
Areas 


With SQL*Forms, you also have some control over whether your 
application reuses context areas. You can exercise this control in three 
places: 

• at the trigger level 

• at the form level 

• at runtime 

For more information on the reuse of context areas by SQL*Forms, refer 
to the SQL*Forms Designer's Reference manual. 


The reuse of context areas in your application determines how much 
parsing and how many context areas the application requires. For 
example, an application that reuses context areas for more than one 
SQL statement does not need as many context areas as an application 
that does not reuse them. However, applications that reuse context 
areas must reparse SQL statements, since results of previous parses 
cannot be retained if the context area is reused. In general, the less 
frequently your application parses, the more context areas it needs. 

Be sure that you have enough context areas to accommodate all of your 
SQL statements. If you reduce parsing, you may need more context 
areas. You may also need to increase the limit on the number of context 
areas permitted for a single user process. You can increase this limit by 
increasing the value of the INIT.ORA parameter OPEN_CURSORS. 

The value of this parameter must be at least 5 and can be no more than 
255. Its default value is 50. 

Be careful not to induce paging and swapping by allocating too much 
memory for additional context areas. The benefits of not reparsing SQL 
statements before each execution can be partially offset by reading 
context areas into memory from disk whenever you need to access 
them. 

You may also want to experiment with allocating fewer context areas 
and allocating more memory to the data dictionary cache or the buffer 
cache. These caches are discussed next in this chapter. 
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Tuning ttit Di*iiork*iy GacKe 

In this section, you will tune the data dictionary cache. The following 
t’ccuoc are covered in this section: 

• what the data dictionary is 

• Yi\\a\ \Yic dictionary cacitc Yb 

• how to monitor the activity of the data dictionary cache 

• how to improve the performance of the data dictionary cache 


What Is the Data The data dictionary refers to the collection of database tables and views 

Dictionary? containing reference information about the database, its structures, and 

its users. Among the data stored in the data dictionary are: 

• names of all database tables and views 

• names and datatypes of columns in database tables 

• rights and privileges of all ORACLE users 

This information is useful as reference material for DBAs, application 
designers, and end users alike. The data dictionary is also accessed 
frequently by ORACLE itself during the parsing of SQL statements. 
This access is essential to the continuing operation of the RDBMS. 


What Is the Data Since the data dictionary is accessed so often by the RDBMS, a special 

Dictionary Cache? location in the SGA is designated to hold dictionary data. This area is 

called the data dictionary cache . The data dictionary cache is shared by 
all ORACLE user processes. 

The data dictionary cache is actually comprised of several caches, each 
holding information for a particular database object. The size of each 
data dictionary cache is determined by an INIT.ORA parameter. The 
INIT.ORA parameters that determine the sizes of the data dictionary 
caches all have names beginning with "DC_". For example, the column 
descriptions cache holds information that describes database table 
columns. The number of entries in this cache is determined by the 
INIT.ORA parameter DC_COLUMNS. For a complete list of all the 
data dictionary caches and the INIT.ORA parameters that determine 
their sizes, refer to Appendix C "Changing INIT.ORA Parameters." 

For best performance when parsing SQL statements, the data 
dictionary caches must be large enough to hold all the most often 
accessed dictionary data. 
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Examining Data 
Dictionary Cache 
Activity 


Examining Recursive Calls 


FIGURE 3-1 
SQL*DBA MONITOR 
STATISTICS USER Display 


If a user process issues a SQL statement that causes a data dictionary 
cache miss, ORACLE must execute additional SQL statements that 
query dictionary tables in the database. These SQL statements are 
referred to as recursive calls because ORACLE calls itself. Recursive 
calls are also generated by space management activity. 

Follow these steps to determine whether data dictionary cache misses 
are affecting the performance of your RDBMS: 

1. Examine recursive calls. 

2. Determine whether any recursive calls are caused by data dictionary 
cache misses. 


The number of recursive calls is reflected by the statistic recursive calls . 
Monitor this statistic through the SQL*DBA MONITOR STATISTICS 
USER display. Figure 3-1 shows the display. To view the display, issue 
the SQL*DBA command: 

SQLDBA> MONITOR STATISTICS USER 

The TOT column shows the cumulative value for each statistic since 
you began viewing the display. In Figure 3-1, you can see that the total 
value for the recursive calls statistic is 0. 
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88 
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10 
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9 

null 

null 
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945 
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5 
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0.00 

0.00 

0.00 

0.00 

0 

user calls 

24. B6 
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24.86 
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recursive calls 

0.00 

0.00 

0.00 

0.00 

0 

Messages sent 

0.71 

0.71 

0.71 

0.71 

5 

Messages received 

0.71 

0.71 

0.71 

0.71 

5 

background tineouts 

0.29 

0.29 

0.29 

0.29 

2 


SQL statements executed immediately after database startup often 
cause recursive calls. These recursive calls occur because the data 
dictionary cache is initially empty and any dictionary access results in 
cache misses. For tuning purposes, examine recursive calls after 
startup is complete. 
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The V$ROWCACHE Table 


If the RDBMS does not continue to make recursive calls after startup, 
your data dictionary cache is probably large enough for your dictionary 
data. If the number of recursive calls accumulates while your 
application is running, then there may be data dictionary cache misses. 
In this case, examine cache activity using the V$ROWCACHE table, as 
described in the following sections. 

Statistics reflecting data dictionary activity are kept in the dynamic 
performance table SYS.V$ROWCACHE. Each row in this table 
contains statistics for one of the data dictionary caches. These statistics 
reflect all data dictionary activity since the most recent database 
startup. The following columns in the V$ROWCACHE table reflect the 
use and effectiveness of each cache: 

PARAMETER This column identifies the particular data 

dictionary cache. For each row, the value in this 
column is the name of the INIT.ORA parameter 
that determines the number of entries in the data 
dictionary cache. 

For example, in the row that contains statistics for 
the file descriptions cache, this column has the 
value 'dc_files.' 

GETS This column shows the total number of requests 

for information on the corresponding data object. 

For example, in the row that contains statistics for 
the file descriptions cache, this column has the 
total number of requests for file descriptions data. 

GETMISSES This column shows the number of data requests 

resulting in cache misses. 

COUNT This column contains the total number of entries in 

the particular cache. The value of this column is 
the value in the INIT.ORA parameter identified in 
the PARAMETER column. 

For example, in the row that contains statistics for 
the file descriptions cache, this column has the 
total number of entries in the file scriptions 
cache. The value in this column is the value of the 
INIT.ORA parameter DC_FILES. 

USAGE This column shows the number of cache entries 

that contain data. If the cache is full, this value is 
equal to the value in the COUNT column. 
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Querying the 
VSROWCACHE Table 


Query the VSROWCACHE table with the SQL statement: 

SELECT PARAMETER, GETS, GETMISSES, COUNT, USAGE 
FROM SYS.V$ROWCACHE 

The output of this query might look like this: 


PARAMETER 

GETS 

GETMISSES 

COUNT 

USAGE 

dc_free_extents 

2497 

127 

50 

50 

dcused extents 

2400 

?1 3 

qn 

r p 

dc segments 

5370 

31 

50 

31 

dc_tablespaces 

2430 

3 

25 

3 

dc tablespaces 

1222 

3 

25 

3 

dc tablespace quotas 

2325 

3 

25 

3 

dc files 

0 

0 

25 

0 

dc users 

27481 

6 

50 

6 

dc rollback segments 

2152 

10 

25 

11 

dc_objects 

138267 

90 

175 

130 

dc_constraints 

18 

7 

150 

7 

dc object ids 

21922 

801 

50 

5 

dc_tables 

162269 

874 

150 

150 

dc synonyms 

12447 

8 

50 

8 

dc sequences 

5049 

4 

20 

1 

dc_usernames 

25105 

20 

5 

20 

dc columns 

912753 

861 

600 

524 

dc_table_grants 

7277 

14 

55 

8 

dc column grants 

0 

0 

100 

0 

dc_indexes 

108060 

45 

80 

51 

dc constraint defs 

0 

0 

200 

0 

dc sequence grants 

0 

0 

20 

0 


22 rows selected. 
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interpreting the 
VSROWCACHE Table 


Examining the first row of the sample query output leads to these 
observations: 


• The PARAMETER column value is 'dc_free_extents'. This 
value indicates that the first row contains statistics for the free 
extent descriptions cache. 

• The GETS column value indicates that there were 2497 requests 
for free extent descriptions data. 

• The GETMISSES column value indicates that 127 of the 
requests for free extent descriptions data resulted in cache 
misses. 

• The COUNT column value indicates that the free extent 
descriptions cache contains 50 entries. 

• The USAGE column value indicates that all 50 of the free extent 
descriptions cache entries contain data. 

Subsequent rows of the sample output contain statistics for other data 
dictionary caches. The PARAMETER column value in each row 
identifies the particular data dictionary cache. For example, the 
PARAMETER column value in the third row is 'dc_segments'. This 
row contains statistics for the segment descriptions cache. The number 
of entries in the segment descriptions cache is determined by the 
INIT.ORA parameter DC_SEGMENTS. 

Note that the value 'dc_tablespaces' appears twice in the PARAMETER 
column. This value appears in two different rows because the value of 
the INIT.ORA parameter DC_TABLESPACES determines the size of 
two different data dictionary caches. The activity of each cache is 
reflected in a separate row of the table. 
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Reducing Data 
Dictionary Cache 
Misses 


Examine cache activity by monitoring the GETS and GETMISSES 
columns. Cache misses are to be expected in some cases. Upon 
database startup, the dictionary cache contains no data. At this point 
any dictionary activity will result in cache misses. As more data is read 
into the cache, the likelihood of cache misses should decrease. 
Eventually the database should reach a "steady state" in which the most 
often used dictionary data is in the cache. At this point, very few cache 
misses should occur. 

For frequently accessed dictionary caches, the ratio of GETMISSES to 
GETS should be less than 10% or 15%. If the ratio of GETMISSES to 
GETS for any dictionary cache continues to increase above this 
threshold while your application is running, you should consider 
increasing the number of entries in that cache. The INIT.ORA 
parameter that determines the number of entries in a dictionary cache 
is identified by the value in the PARAMETER column. 


Reducing Unused Data 
Dictionary Cache 
Entries 


Examine also the COUNT and USAGE columns. If any row in the 
V$ROWCACHE table has a USAGE value that is significantly less than 
its COUNT value, then the cache has never been completely filled. In 
this case, you can afford to reduce the number of cache entries. By 
reducing the cache size, you can save memory to allocate to other 
ORACLE memory structures. 
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iming the Buffer Cache 

In this section, you will learn how to tune the buffer cache. The 
following issues are covered in this section: 

• what the buffer cache is 

• how the buffer cache improves performance 

• how to monitor buffer cache performance 

• how to improve buffer cache performance 


What Is the Buffer 
Cache? 


The buffer cache is the area in the SG A that holds copies of database 
blocks. These blocks contain data that is frequently accessed by 
ORACLE processes. These blocks contain data for: 

• tables 

• indexes 

• rollback segments 

• clusters 

Each buffer in the cache can hold a single ORACLE data block. The 
number of buffers in the cache is determined by the INIT.ORA 
parameter DB_BLOCK_BUFFERS. The default value for this parameter 
depends upon your operating system and is usually appropriate for 
smaller computers. The size of the cache is often increased on larger 
computers to improve performance. 


Performance Benefits By holding copies of blocks in memory, the buffer cache reduces the 
of the Buffer Cache time necessary to access data. The buffer cache has two main 

performance advantages: 

• ORACLE user processes can avoid disk I/O by accessing data 
stored in the buffer cache. 

• Since the buffer cache is in shared memory, all ORACLE 
processes may access it. Once one process has read a block into 
the cache, all other processes can access that block as well. 
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Examining Buffer 
Cache Activity 


ORACLE collects these statistics that reflect data access: 

Logical Reads The value of this statistic is the total number of 

requests for data. This value 

satisfied by access to buffers in memory. 

Physical Reads 7’he value of tfus statistic is me total numpor of 
requests for data resulting in access to database 
files on disk. 

Hit Ratio The value of this statistic is the percentage of total 

data requests satisfied entirely by memory access. 

ORACLE calculates the Hit Ratio statistic from the Logical Reads and 
Physical Reads statistics with this formula: 

Hit Ratio = ( Logical Reads - Physical Reads ) / Logical Reads 

Monitor these statistics through the SQL*DBA MONITOR I/O display. 
Figure 3-2 shows this display. To view the display, issue the SQL*DBA 
command: 

SQLDBA> MONITOR 10 

The SQL*DBA MONITOR I/O display has two parts: 

Interval The left half of the display is labelled Interval. 

Statistics in this half of the display reflect the I/O 
that has occurred since ORACLE last updated the 
display. 

Cumulative The right half of the display is labelled Cumulative. 

Statistics in this half of the display reflect I/O that 
has occurred since you began viewing the display. 

In the Interval display in Figure 3-2, you can see that the value of Logical 
Reads is 114, the value of Physical Reads is 11, and the Hit Ratio is 90%. 

In the Cumulative display, the value of Logical Reads is 3215, the value of 
Physical Reads is 261, and the Hit Ratio is 92%. 
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FIGURE 3-2 

SQL*DBA MONITOR I/O 
Display 


Reducing Buffer Cache 
Misses 
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If your Hit Ratio is low, say less than 60% or 70%, then you may want to 
increase the number of buffers in the cache to improve performance. 

To make the buffer cache larger, increase the value of the INIT.ORA 
parameter DBBLOCKBUFFERS. 

ORACLE can collect statistics that estimate the performance gain that 
would result from increasing the size of your buffer cache. With these 
statistics, you can estimate how many buffers to add to your cache. 
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The X$KCBRBH Table 


The virtual table SYS.X$KCBRBH contains statistics that estimate the 
performance of a larger cache. Each row in the table reflects the relative 
performance value of adding a buffer to the cache. The following are 
the columns of the X$KCBRBH table: 

INDX The value of this column is one less than the 

number of buffers that would potentially be added 
to the cache. 

COUNT The value of this column is the number of 

additional cache hits that would be obtained by 
adding additional buffer number INDX+1 to the 
cache. 


For example, in the first row of the table, the INDX value is 0 and the 
COUNT value is the number of cache hits to be gained by adding the 
first additional buffer to the cache. In the second row, the INDX value 
is 1 and the COUNT value is the number of cache hits for the second 
additional buffer. 


Enabling the X$KCBRBH The collection of statistics in the X$KCBRBH table is controlled by the 
Table INIT.ORA parameter DBJBLOCK JLRU_EXTENDED_STATISTICS. 

The value of this parameter determines the number of rows in the 
X$KCBRBH table. The default value of this parameter is 0, which 
means the default behavior is to not collect statistics. 


To enable the collection of statistics in the X$KCBRBH table, set the 
value of DB_BLOCK_LRU_EXTENDED_STATISTICS. For example, if 
you set the value of the parameter to 100, ORACLE will collect 100 
rows of statistics, each row reflecting the addition of one buffer, up to 
100 extra buffers. 

Collecting these statistics incurs some performance overhead. This 
overhead is proportional to the number of rows in the table. Collect 
statistics only when tuning the buffer cache. When you are not tuning, 
disable the collection of statistics for best performance. 
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Querying the X$KCBRBH 
Table 


Grouping Rows in the 
X$KCBRBH Table 


From the information in the X$KCBRBH table, you can predict the 
potential gains of increasing the cache size. For example, to determine 
how many more cache hits would occur if you added 20 buffers to the 
cache, query the X$KCBRBH table with the SQL statement: 

SELECT SUM(COUNT) ACH 
FROM SYS.X$KCBRBH 
WHERE INDX <20 

You can also determine how these additional cache hits would affect 
the Hit Ratio. Use the following formula to calculate the Hit Ratio based 
on the values of the statistics Logical Reads and Physical Reads and the 
number of additional cache hits (ACH) returned by the query: 

Hit Ratio = ( Logical Reads - Physical Reads + ACH) / Logical Reads 

Another way to examine the X$KCBRBH table is to group the 
additional buffers in large intervals. You can query the table with a 
SQL statement similar to this one: 

SELECT 250*TRUNC(INDX/250)+ 11 | ' to ' | |250* (TRUNC (INDX/250)+1) INTERVAL, 
SUM(COUNT) CACHE_HITS 
FROM SYS.X$KCBRBH 
GROUP BY TRUNC(INDX/250) 

The result of this query might look like this: 

INTERVAL CACHE_HITS 

1 to 250 
251 to 500 
501 to 750 
751 to 1000 

where: 

INTERVAL 

CACHE HITS 
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16080 

10950 

710 

23140 


is the interval of additional buffers to be added to 
the cache. 

is the number of additional cache hits to be gained 
by adding the buffers in the INTERVAL column. 
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Examining the query output leads to these observations: 

• If 250 buffers were added to the cache, 16,080 cache hits would 
be gained. 

• If 250 more buffers were added for a total of 500 additional 
buffers, 10,950 cache hits would be gained in addition to the 
16,080 cache hits from the first 250 buffers. This means that 
adding 500 buffers would yield a total of 27,030 additional 
cache hits. 

• If 250 more buffers were added for a total of 750 additional 
buffers, 710 cache hits would be gained, yielding a total of 
27,740 additional cache hits. 

• If 250 buffers were added to the cache for a total of 1000 
additional buffers, 23,140 cache hits would be gained, yielding 
a total of 50,880 additional cache hits. 

Based on these observations, you should decide how many buffers to 
add to the cache. In this case, you may make these decisions: 

• It is wise to add 250 or 500 buffers, provided memory resources 
are available. Both of these increments offer significant 
performance gains. 

• It is unwise to add 750 buffers. Nearly the entire performance 
gain made by such an increase can be made by adding 500 
buffers instead. Also, the memory allocated to the additional 
250 buffers may be better used by some other ORACLE 
memory structure. 

• It is wise to add 1000 buffers, provided memory resources are 
available. The performance gain from adding 1000 buffers to 
the cache is significantly greater than the gains from adding 
250, 500, or 750 buffers. 
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Removing 

Unnecessary Buffers 


The X$KCBCBH Table 


Enabling the X$KCBCBH 
Table 


If your Hit Ratio is high, your cache is probably large enough to hold 
your most frequently accessed data. In this case, you may be able to 
reduce the cache size and still maintain good performance. To make 
the buffer cache smaller, reduce the value of the INIT.ORA parameter 
DB_BLOCK_BUFFERS. You can apply any leftover memory to other 
ORACLE memory structures. 

ORACLE can collect statistics to predict buffer cache performance 
based on a smaller cache size. Examining these statistics can help you 
determine how small you can afford to make your buffer cache without 
adversely affecting performance. 

The virtual table SYS.X$KCBCBH contains the statistics that estimate 
the performance of a smaller cache. The X$KCBCBH table is similar in 
structure to the X$KCBRBH table. The following are the columns of the 
X$KCBCBH table: 

INDX The value of this column is one less than the 

potential number of buffers in the cache. 

COUNT The value of this column is the number of cache 

hits attributable to buffer number INDX+1. 

The number of rows in this table is equal to the number of buffers in 
your buffer cache. Each row in the table reflects the number of cache 
attributed to a single buffer. For example, in the second row, the INDX 
value is 1 and the COUNT value is the number of cache hits for the 
second buffer. In the third row, the INDX value is 2 and the COUNT 
value is the number of cache hits for the third buffer. 

The first row of the table contains special information. The INDX value 
is 0 and the COUNT value is the total number of blocks moved into the 
first buffer in the cache. 

The collection of statistics in the X$KCBCBH table is controlled by the 
INIT.ORA parameter DB_BLOCK_LRU_STATISTICS. The value of this 
parameter determines whether ORACLE collects the statistics. The 
default value for this parameter is FALSE, which means that the default 
behavior is to not collect statistics. 

To enable the collection of statistics in the X$KCBCBH table, set the 
value of DB_BLOCK_LRU_STATISTICS to TRUE. 

Collecting these statistics incurs some performance overhead. Collect 
statistics only when you are tuning the buffer cache. When you are not 
tuning, disable the collection of statistics for best performance. 
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Querying the X$KCBCBH 
Table 


Grouping Rows in the 
X$KCBCBH Table 


From the information in the X$KCBCBH table, you can predict the 
number of additional cache misses that would occur if the number of 
buffers in the cache were reduced. If your buffer cache currently 
contains 100 buffers, you may want to know how many more cache 
misses would occur if it had only 90. To determine the number of 
additional cache misses, query the X$KCBCBH table with the SQL 
statement: 

SELECT SUM(COUNT) ACM 
FROM SYS.X$KCBCBH 
WHERE INDX >= 90 

You can also determine the Hit Ratio based on this cache size. Use the 
following formula to calculate the Hit Ratio based on the values of the 
statistics Logical Reads and Physical Reads and the number of additional 
cache misses (ACM) returned by the query: 

Hit Ratio = ( Logical Reads - Physical Reads - ACM ) / Logical Reads 


Another way to examine the X$KCBCBH table is to group the buffers in 
intervals. For example, if your cache contains 100 buffers, you may 
want to divide the cache into four 25-buffer intervals. You can query 
the table with a SQL statement similar to this one: 

SELECT 25*TRUNC(INDX/25)+1 I I' to 9 I |25*(TRUNC(INDX/25)+1) INTERVAL, 
SUM(COUNT) CACHE_HITS 
FROM SYS.X$KCBCBH 
WHERE INDX > 0 
GROUP BY TRUNC(INDX/25) 

Note that the WHERE clause prevents the query from collecting 
statistics from the first row of the table. The result of this query might 
look like this: 


INTERVAL CACHE HITS 


1 to 25 
26 to 50 
51 to 75 
76 to 100 

where: 

INTERVAL 


1900 

1100 

1360 

230 

is the interval of buffers in the cache. 


cache hits is the number of cache hits attributable to the 

buffers in the INTERVAL column. 
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Examining the query output leads to these observations: 

• The last 25 buffers in the cache (buffers 76 to 100) contribute 
230 cache hits. If the cache were reduced in size by 25 buffers, 
230 cache hits would be lost. 

• The third 25-buffer interval (buffers 51 to 75) contributes 1,360 
cache hits. If these buffers were removed from the cache, 1,360 
cache hits would be lost in addition to the 230 cache hits lost 
for buffers 76 to 100. Removing 50 buffers would result in 
losing a total of 1,590 cache hits. 

• The second 25-buffer interval (buffers 26 to 50) contributes 
1,100 cache hits. Removing 75 buffers from the cache would 
result in losing a total of 2,690 cache hits. 

• The first 25 buffers in the cache (buffers 2 to 25) contribute 
1,900 cache hits. Removing all 100 buffers from the cache 
would result in losing all cache hits. 

Based on these observations, you should decide whether to reduce the 
size of the cache. In this case, you may make these decisions: 

• If memory is scarce, it may be wise to remove 25 buffers from 
the cache. The buffers 76 to 100 contribute relatively few cache 
hits compared to the total cache hits contributed by the entire 
cache. Removing 25 buffers will not significantly reduce cache 
performance, and the leftover memory may be better used by 
other ORACLE memory structures. 

• It is unwise to remove more than 25 buffers from the cache. 

For example, removing 50 buffers would reduce cache 
performance significantly. The cache hits contributed by these 
buffers is a significant portion of the total cache hits. 
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Reallocating Memory 

After resizing your ORACLE memory structures, re-evaluate the 
performance of context areas, the data dictionary cache, and the buffer 
cache. If you have reduced the memory consumption of any one of 
these structures, you may want to allocate more memory to another 
structure. For example, if you have reduced the size of your buffer 
cache, you may now want to take advantage of the additional available 
memory by using it for context areas. 

Tune your operating system again. Resizing ORACLE memory 
structures may have changed ORACLE memory requirements. In 
particular, be sure paging and swapping is not excessive. For example, 
if the size of the data dictionary cache or the buffer cache has increased, 
the SGA may be too large to fit into main memory. In this case, the 
SG A could be paged or swapped. 

In the process of reallocating memory, you may determine that the 
optimum size of ORACLE memory structures requires more memory 
than your operating system can provide. In this case, you may improve 
the performance of your RDBMS even further by adding more memory 
to your computer. 


3-26 ORACLE RDBMS Performance Tuning Guide 









4 



Tuning I/O 


T his chapter presents Step Three of the tuning process: tuning I/O. 

This chapter teaches you how to avoid I/O bottlenecks that could 
prevent the ORACLE RDBMS from performing at its maximum 
potential. In this chapter you learn how to: 

• reduce disk contention 
• allocate space in data blocks 
• avoid dynamic space management 
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The Importance of Tuning 1/0 


The performance of many software applimHrmc ic 
disk I/O. Often, CPU activity must be suspended while I/O activity 
completes. Such an application is said to be "I/O bound." Version 6.0 
of the ORACLE RDBMS is designed so that performance need not be 
limited by I/O. 


It is important to tune I /0 after foUowme the melton aUocatm 
recommendations presented in Chapters 'Tuning Memory Allocation. 
Lmapter 3 shows you how to allocate memory in nrrlor fn I. /O 

a minimum. After reaching this minimum, follow the instructions in 
this chapter in order to perform the necessary I/O as efficiently as 
possible. 


The Database Writer Process (DBWR) 


The Database Writer process (DBWR) is an ORACLE background 
process responsible for the management of the buffer cache. The 
DBWR process writes modified data blocks from the buffer cache in the 
System Global Area (SG A) to database files on disk. DBWR performs a 
major part of the disk I/O necessary for the operation of the ORACLE 
RDBMS. 

In releases of ORACLE Version 6.0 prior to Version 6.0.27, buffer cache 
management was a focal point of tuning the RDBMS. However, DBWR 
has been enhanced for ORACLE Version 6.0.27. DBWR now manages 
the buffer cache more efficiently and should not require tuning 
attention. 

For more information about the role of DBWR in buffer cache 
management, refer to Appendix B "The Database Writer Process 
(DBWR)" of this Guide. 
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Reducing Disk Contention 

In this section you will learn how to reduce disk contention. The 
following issues are discussed in this section: 

• what disk contention is 

• how to monitor disk activity 

• how to reduce disk activity 


What Is Disk Disk contention occurs when multiple processes try to access the same 

Contention? disk simultaneously. Most disks have limits on both the number of 

accesses and the amount of data they can transfer per second. When 
these limits are reached, processes may have to wait to access the disk. 


Monitoring Disk Disk activity is reflected by: 

ActlVlty • ORACLE FILE I/O statistics 

• operating system statistics 


The ORACLE RDBMS compiles ORACLE FILE I/O statistics that 
reflect disk access to ORACLE files. Your operating system may also 
keep statistics for disk access to all files. 

Monitoring ORACLE Disk Examine disk access to ORACLE files through the SQL*DBA 
Activity MONITOR FILE I/O display. Figure 4-1 shows this display. To view 

the display, issue the SQL*DBA command: 

SQLDBA> MONITOR FILE 

The SQL*DBA MONITOR FILE I/O display lists all the database files 
accessed by the ORACLE RDBMS, along with statistics reflecting their 
I/O activity. For each database file, observe the statistics: 

Request Rate This is the average number of reads from each 

Read/s database file per second. 


Request Rate This is the average number of writes to each 

Write/s database file per second. 


Batch Size This is the average number of data blocks written 

blks/W to each database file in a single write. 

The total I /O rate for a single disk is the sum of Request Rate Read/s and 
Request Rate ]Alrite/s for all the ORACLE database files managed by the 
ORACLE instance on that disk. Determine this value for each of your 
disks. 
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FIGURE 4-1 

SQL*DB A MONITOR FILE I/O 

Display 


Monitoring Operating 
System Disk Activity 


Distributing I/O 


Also determine the total number of blocks written to each disk per 
second. For a single file, the number of blocks written per second is the 
product of Request Rate Write/s and Batch Size blks/W. The total number 
of blocks written to each disk is the sum of the blocks written to all of 
its files. 


ORACLE File 1/0 Monitor 

Pp'j't/rti /tote 6 to A Si+ m n«raf<uiiM i 1 rtt 

File Nsmc Read/'s Urite/s blks/R blks/U ns/Read ws/Urlte 

Thu Jun 22 14iZ0i35 

total oiocks 

Read Urltten 

DISKSMKT4: [HCJMAILJU60MAIL SYS1.0RA 
0.40 1.00 1.00 

1.00 

0.00 

0.00 

4705 

2803 

DI5K$MKT3«[HQMAI LIUG0MAIL TBL A01.ORA 
3.60 1.Z0 1.00 

1.00 

0.00 

0.00 

Z0477 

3Z55 

DISKSMKTl:CHQMAIL3U60MAIL TBL B01.ORA 
8.20 1.20 Z.00 

1.00 

0.00 

0.00 

3Z1Z7 

2884 

DISKSMKT4:CHQMAIL]U60MAIL TBL B0Z.ORA 
4.20 Z.80 1.00 

1.00 

0.00 

0.00 

Z0364 

3Z08 


Disks holding database files and redo log files may also hold files that 
are not related to ORACLE. Access to such files can only be monitored 
through operating system facilities, rather than through SQL*DBA. 

Use your operating system facilities to examine the total I/O to your 
disks. Try to reduce any heavy access to disks that contain ORACLE 
files. 


Consider the statistics in the SQL*DBA MONITOR FILE I/O display 
and your operating system facilities. Consult your hardware 
documentation to determine the limits on the capacity of your disks. 
Any disks operating at or near full capacity are potential sites for disk 
contention. For example, 40 or more I/Os per second is excessive for 
most disks on VMS or UNIX operating systems. 

To reduce the activity on an overloaded disk, move one or more of its 
heavily accessed files to a less active disk. Apply this principle to each 
of your disks until they all have roughly the same amount of I/O. This 
is referred to as distributing I/O. 
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Separating Database Files 
and Redo Log Files 


This section discusses guidelines for distributing I/O: 

• Separate database files and redo log files on different disks. 

• Separate, or "stripe," table data on different disks. 

• Separate tables and indexes on different disks. 

• Reduce disk I/O not related to the ORACLE RDBMS. 

ORACLE processes constantly access database files and redo log files. 

If these files are on common disks, there is potential for disk contention. 

Place each database file on a separate disk. Multiple processes can then 
access different files concurrently without disk contention. 

Place all redo log files on a separate disk with no other activity. Redo 
log files are written by the Log Writer process (LGWR) when a 
transaction is committed. Since LGWR writes redo log files 
sequentially, LGWR can write much faster if there is no concurrent disk 
activity. 

Dedicating a separate disk to redo log files usually ensures that LGWR 
will run smoothly with no further tuning attention. Performance 
bottlenecks related to LGWR are rare. For information on LGWR, refer 
to Chapter 5 'Tuning Contention." 

Dedicating a separate disk to redo log files is also an important safety 
precaution. It ensures that both database files and redo log files cannot 
be lost in a single disk failure. 
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"Striping"is (Ik practice orcrrvrcrmg a targe tame *> aata into Milan 
portions and storing these portions in separate database files on 
separate disks. This permits multiple processes to access different 
portions of the table concurrently without disk contention. "Striping'' is 
particularly helpful in optimizing random access to tables with many 
rows. 


To create a "striped" table: 


1. Create a tablespace with the CREATE TABLESPACE statement. 
Specify the database files in the DATAFILE clause. Each of the files 
should be on a different disk. 


CREATE TABLESPACE STRIPEDTABSPACE 
DATAFILE 'FILE_ON_DISK_l' 
'FILE_ON_DISK_2' 
'FILE_ON_DISK_3' 

'FILE_ON_DISK_4' 
'FILE ON DISK 5' 


SIZE 500K, 
SIZE 500K, 
SIZE 500K, 
SIZE 500K, 
SIZE 500K 


2. Then create the table with the CREATE TABLE statement. Specify the 
newly created tablespace in the TABLESPACE clause. 


Also specify the size of the table extents in the STORAGE clause. 
Store each extent in a separate datafile. The table extents should be 
slightly smaller than the datafiles in the tablespace to allow for 
overhead. For instance: 

CREATE TABLE STRIPEDTAB 

( COL_l NUMBER(2), 

C0L_2 CHAR(10) ) 

TABLESPACE STRIPEDTABSPACE 
STORAGE ( INITIAL 495K NEXT 495K 

MINEXTENTS 5 PCTINCREASE 0 ) 

These steps result in the creation of table STRIPEDTAB. STRIPEDTAB 
has 5 initial extents, each of size 495 kilobytes. Each extent takes up one 
of the datafiles named in the DATAFILE clause of the CREATE 
TABLESPACE statement. These files are all on separate disks. These 5 
extents are all allocated immediately, since MINEXTENTS is 5. For 
more information on MINEXTENTS and the other storage parameters, 
refer to the section "Segments and Extents" later in this chapter. 
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Separating Tables and 
Indexes 


Eliminating Other Disk 
I/O 


Place frequently accessed database structures in separate database files 
on separate disks. To do this, you must know which of your database 
structures are used often. For example, separate an often used table 
from its index. This separation distributes the I/O to the table and 
index across separate disks. 

Follow these steps to separate a table and its index: 

1. Create a tablespace with the CREATE TABLESPACE statement. 
Specify the database file in the DATAFILE clause: 

CREATE TABLESPACE TABSPACE_1 

DATAFILE 'FILE_ON_DISK_l' 

2. Create the table with the CREATE TABLE statement. Specify the 
tablespace in the TABLESPACE clause: 

CREATE TABLE TAB_1 

( COL_l NUMBER(2), 

COL_2 CHAR(10) ) 

TABLESPACE TABSPACE_1 

3. Create another tablespace. Specify a database file on another disk: 

CREATE TABLESPACE TABSPACE_2 

DATAFILE 'FILE_ON_DISK_2' 

4. Create the index. Specify the new tablespace: 

CREATE INDEX IND_1 ON TAB_1 (COL_l) 

TABLESPACE TABSPACE_2 

These steps result in the creation of table TAB_1 in the file 
FILE_ON_DISK_l and the creation of index IND_1 in the file 
FILE_ON_DISK_2. 

If possible, eliminate I/O not related to ORACLE on disks that contain 
ORACLE files. This measure is especially helpful in optimizing access 
to redo log files. Not only does this reduce disk contention, it also 
allows you to monitor all activity on such disks through the SQL*DBA 
MONITOR FILE I/O display. 
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Allocating Space in Data Blocks 


Table data in the database is stored in data blocks. In this section, you 
will learn how to allocate space within data blocks for best 
performance. The following issues are discussed in this section: 


• what is stored inside data blocks 


• how to control data storage 

• how to store data most efficiently based on your application 


Data Block Format 




All data blocks contain space for: 

• general information about the block 

• information about clustered tables and the cluster key, if the 
block stores clustered data 

• information about the rows in the block 

• the actual row data 


The size of an ORACLE database block is specified in bytes by the 
INIT.ORA parameter DB_BLOCK_SIZE. 

At any time, a portion of the space in a data block reserved for row data 
may be empty. This space is referred to as free space. For more 
information on the format of a data block, refer to Chapter 5 "User 
Database Objects" of the ORACLE RDBMS Database Administrator's 
Guide. 

Data Block Space The SQL statements INSERT, UPDATE, and DELETE can change the 

Management amount of space in a data block that contains data. 

Space is used when: 

• an INSERT statement adds rows to the table that uses the block 

• an UPDATE statement increases the amount of data in a row 
that is already stored in the block 

Space is freed when: 

• a DELETE statement removes rows that are stored in the block 

• an UPDATE statement reduces the amount of data in a row 
that is stored in the block 
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Chaining Blocks 


Free Lists 


Data Blocks on Free Lists 


If an UPDATE statement increases the amount of data in a row so that 
the row no longer fits in the block, another block must be used to hold 
the remaining data. This is called chaining rows. Dynamic space 
management, especially chaining, is detrimental to RDBMS 
performance. ORACLE provides you with control over space usage 
within blocks. You should regulate space usage so that there is enough 
free space in each data block to accommodate expansion of the rows 
stored there. 

A free list is a list of data blocks that contain free space. Free lists are 
used to keep track of blocks that have enough free space to accept new 
rows. 

Every table must have at least one free list. When an ORACLE process 
inserts a row into a table, the process must first find a data block with 
free space to hold the data. To find such a block, the process searches 
one of the table's free lists. The number of free lists for a table is 
determined by the value of the INIT.ORA parameter 
FREE_LIST_PROC when the table is created. 

These two parameters control the addition and removal of data blocks 
from free lists and set limits on the amount of free space in data blocks: 

PCTFREE This is the percentage of the block reserved to 

accommodate row expansion. If the percentage of 
a block containing free space falls below PCTFREE, 
the block is removed from the free list and no new 
rows may be added to the block. However, 
existing rows may be expanded. The default value 
for PCTFREE is 10. 

PCTUSED ORACLE will try to keep this percentage of the 

block filled with data. If the percentage of a block 
that holds data falls below PCTUSED the block is 
put on a free list and new rows may be added to 
that block. The default value for PCTUSED is 40. 

You can specify the values of PCTFREE and PCTUSED for a table, 
index, or cluster when you create it. You can also specify default values 
for PCTFREE and PCTUSED when you create a tablespace. 

The sum of PCTUSED and PCTFREE cannot exceed 100. 
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Example of Data Block 
Space Management 


PCTFREE and PCTUSED can be specified in the Data Definition 
Language (DDL) statements: 

• CREATE TABLE 

• ALTER TABLE 

• CREATE CLUSTER 

• ALTER CLUSTER 

PCTFREE can also be used in a CREATE INDEX statement to specify 
the amount of free space left in index blocks when the index is created. 
This free space may be used to accommodate either new index entries 
or expansion of index data. 

This example shows you how ORACLE moves data blocks to and from 
free lists based on the values of PCTFREE and PCTUSED. Consider the 
SQL statement that creates the DEPT table: 

CREATE TABLE DEPT 

( DEPTNO NUMBER(2) , 

DNAME CHAR(14), 

LOC CHAR(13) ) 

PCTFREE 5 PCTUSED 75 

Space management in the blocks of the DEPT table are governed by a 
PCTFREE value of 5 and a PCTUSED value of 75. ORACLE reserves 
5% of the block for expansion of rows and tries to keep the block 75% 
full. 

A single block may accept new rows as long as at least 5% of the block 
is free space. If a database operation fills more than 95% of the block 
(so that less than 5% is free), ORACLE removes the block from the free 
list. The remaining free space can only be filled by increasing the 
length of the rows already stored. 

If enough data is removed from the block, either by removing entire 
rows or by reducing the amount of data in the rows, so that less than 
75% of the block is used, ORACLE adds the block to a free list. At this 
point the block may accept new rows until less than 5% of the block is 
free space. 
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Choosing Limits for 
Free Space 


Choosing PCTFREE 


Choosing PCTUSED 


You can improve the performance of some database operations by 
establishing space management guidelines for your data blocks. To do 
this, you must be familiar with your application. In particular, you 
must know what database operations are performed most often on 
each of your tables. 

The value of PCTFREE affects space management for blocks that are 
currently on a free list. 

A low value for PCTFREE can improve the performance of full table 
scans. When a table is loaded with a low PCTFREE, the table data can 
fit into fewer blocks because ORACLE leaves less free space in each 
block. A full table scan can then read the entire table by accessing 
fewer blocks. Very low values for PCTFREE should be used for tables 
that are only queried and never modified. However, this increases the 
likelihood of chaining rows that are modified. 

A high value for PCTFREE reduces the likelihood of chaining expanded 
rows from block to block. When a table is loaded with a high 
PCTFREE, ORACLE leaves more free space in each block to 
accommodate the expansion of rows. Rows are likely to expand if they 
contain fields with varying length or null values. Leaving space for 
rows to expand reduces the likelihood of an expanded row chaining to 
another block. However, a high value for PCTFREE increases the 
number of blocks that must be read for a full table scan. 

The value of PCTUSED affects space management for blocks that have 
been removed from a free list. 

A low value of PCTUSED reduces the likelihood of chaining expanded 
rows from block to block. This is because ORACLE adds blocks back to 
free lists when they have more free space. This means that blocks on 
free lists tend to have more free space to accept long rows. 

A high value for PCTUSED reduces the amount of free space in blocks 
on the free list. This is because ORACLE adds blocks back to free lists 
when they have less free space. A high value for PCTUSED stores data 
in a more space-efficient manner, but it increases the likelihood of 
chaining long rows. High values for PCTUSED also tend to increase 
the frequency with which blocks are added back to free lists. Heavy 
free list management also takes processing time and can diminish 
RDBMS performance. 
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Avoiding Dynamic Space Management 


When a database object such as a table is created, space is allocated in 
the database for the data. This space is called a segment. If subsequent 
database operations cause the data to grow and exceed the space 
allocated, ORACLE extends the segment. Dynamic extension can 
reduce performance. This section discusses: 


• how segments are allocated 

• how segments are extended dynamically 

• how to detect dynamic extension 

• how to allocate enough space for your data to avoid dynamic 
extension 


Segments 


and Extents 


ORACLE stores the following data in segments: 

data segments A data segment stores all the data for a single 

table or cluster. 


index segments 


rollback segments 


temporary segments 


bootstrap segment 


An index segment stores all the data for a 
single index. 

Rollback segments store information 
necessary to reverse changes to the database. 

Temporary segments provide temporary 
workspace for ORACLE to perform certain 
database operations, such as sorting data. 

The bootstrap segment contains the 
definitions of dictionary tables that are 
loaded at database startup. 
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Segments are divided into smaller portions of space called extents. An 
extent is made up of contiguous data blocks. The number and size of 
the extents in a segment are determined by the storage parameters in 
effect when the segment is created. The following are the storage 
parameters: 


INITIAL 

This parameter determines the size of the first, or 
initial extent in the segment. The initial extent is 
always allocated when the segment is created. 

The value of INITIAL is expressed in bytes. The 
default value is 10240 bytes. Values of this 
parameter are rounded to the nearest ORACLE 
block size. The size of ORACLE blocks is 
determined the INIT.ORA parameter 
DB_BLOCK_SLZE. 

NEXT 

This parameter determines the size of the second 
and every incremental extent in the segment. 

The value of NEXT is expressed in bytes. The 
default value is 10240 bytes. Values of this 
parameter are rounded to the nearest ORACLE 
block size. 

MINEXTENTS 

This parameter determines the minimum number 
of extents for the segment. These extents are 
allocated when the segment is created. The default 
value is 1. 

MAXEXTENTS 

This parameter determines the maximum number 
of total extents for the segment. The default value 
is 99. 

PCTINCREASE 

This parameter determines the percent of growth 
of subsequent extents. After the second extent, 
each extent is PCTINCREASE percent larger than 
the one preceding it. The default value is 50. 

If PCTINCREASE is 0, all extents after the second 
also have the size of NEXT. 
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You can specify the values for the storage parameters in the STORAGE 
clause of any SQL statements that create or alter these database objects: 

• tables 

• clusters 

• indexes 

• rollback segments 

For example, consider this CREATE TABLE statement: 

CREATE TABLE ACCOUNTS 
{ ACC_NUM NUMBER, 

BALANCE NUMBER(11,2) ) 

STORAGE ( INITIAL 100K NEXT 50K 

MINEXTENTS 1 MAXEXTENTS 50 
PCTINCREASE 5 ) 

This statement creates the ACCOUNTS table with an initial extent of 
100 kilobytes, the value of INITIAL. The size of the second extent, if 
necessary, will be 50 kilobytes, the value of NEXT. To calculate the size 
of the third extent, increase the size of the second extent by 5%, the 
value of PCTINCREASE. The calculated size for the third segment is 
52.5 kilobytes. To obtain the actual size of the third extent, round the 
calculated size to the nearest ORACLE block size. 

Storage parameter values can also be specified in the DEFAULT 
STORAGE clause of these DDL statements: 
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• CREATE TABLESPACE 

• ALTER TABLESPACE 

For example, consider this CREATE TABLESPACE statement: 

CREATE TABLESPACE TABSPACE_2 

DATAFILE 'TABSPACE_FILE2.DAT' SIZE 20M 
DEFAULT STORAGE ( INITIAL 10K NEXT 50K 

MINEXTENTS 1 MAXEXTENTS 999 
PCTINCREASE 10 ) 

ONLINE 

The values specified in a DEFAULT STORAGE clause serve as defaults 
for the storage parameters of segments created in the tablespace. If you 
create a table in the TABSPACE_2 tablespace without using a 
STORAGE clause, the storage parameters of the table segment would 
default to the values in the DEFAULT STORAGE clause of the CREATE 
TABLESPACE statement. 
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Segment Extension 


Detecting Dynamic 
Extension 


FIGURE 4-2 
SQL*DBA MONITOR 
STATISTICS USER Display 


ORACLE allocates segments and extents while creating the 
corresponding database objects. For example, when you issue a 
CREATE TABLE statement, ORACLE allocates a table segment. 
ORACLE also allocates the minimum number of extents for the 
segment specified by the parameter MINEXTENTS. As you load data 
into the table, the data fills these extents. 

If the amount of data in the table ever exceeds the space in the first 
MINEXTENTS, ORACLE dynamically creates more extents in the table 
segment based on the values of the storage parameters. This process is 
called extension. Dynamic extension can reduce performance. For this 
reason, you should eliminate excessive dynamic extension. 


Dynamic extension causes ORACLE to execute SQL statements in 
addition to those SQL statements issued by user processes. These SQL 
statements are referred to as recursive calls , because ORACLE calls itself. 
Recursive calls are also generated by data dictionary cache misses. 

The number of recursive calls performed by ORACLE is reflected by 
the statistic recursive calls. Monitor this statistic through the SQL*DBA 
MONITOR STATISTICS USER display. Figure 4-2 shows the display. 
To view the display, issue the SQL*DBA command: 

SQLDBA> MONITOR STATISTICS USER 

In Figure 4-2, you can see that the value for recursive calls is 0. 



ORACLE 

Statistics Monitor 

Thu 

Jun 22 

ORACLE PID: 0 

Session 

«: 0 

User None: 

SYSTEM STATISTICS 

Statistic Nane 

CUR 

AUG 

MAX 

MIN 

TOT 

logons 

2 

null 

null 

null 

626 

current logons 

1 

null 

null 

null 

00 

cuMulative opened cu 

10 

null 

null 

null 

5020 

current open cursors 

9 

null 

null 

null 

945 

user connits 

0.71 

0.71 

0.71 

0.71 

5 

user rollbacks 

0.00 

0.00 

0.00 

0.00 

0 

user calls 

24.06 

24.06 

24.06 

24.06 

174 

recursive calls 

0.00 

0.00 

0.00 

0.00 

0 

Messages sent 

0.71 

0.71 

0.71 

0.71 

5 

Messages received 

0.71 

0.71 

0.71 

0.71 

5 

background tineouts 

0.29 

0.29 

0.29 

0.29 

2 


Tuning I/O 4-15 








ORACLE often makes recursive calls shortly after startup due to data 
dictionary cache misses. For this reason, you should monitor recursive 
calls only after startup is complete. If ORACLE continues to make 
recursive calls after startup, determine whether these recursive calls are 
due to data dictionary cache misses. For more information on the data 
dictionary cache, refer to Chapter 3 "Tuning Memory Allocation." 

If you determine that an excess of recursive calls is not caused by data 
dictionary cache misses, these recursive calls may be caused by 
dynamic extension. In this case, you should try to reduce this extension 
by allocating larger extents. 


Allocating Extents 


Follow these steps to avoid dynamic extension: 

1. Determine the maximum size of your database object. For formulas to 
predict how much space to allow for a table, refer to Chapter 16 
"Space Management" of the ORACLE RDBMS Database 
Administrator's Guide. 

2. Choose storage parameter values so that ORACLE will allocate 
extents large enough to accommodate all of your data when you 
create the database object. 

Larger extents tend to benefit performance for these reasons: 

• Since blocks in a single extent are contiguous, one large extent 
is more contiguous than many small extents. ORACLE can 
read one large extent from disk with a single multi-block read. 

• Segments with larger extents are less likely to be extended. 

However, since large extents require more contiguous blocks, ORACLE 
may have difficulty finding enough contiguous space to store them. 
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A PT E R 


Tuning 

Contention 



T his chapter presents Step Four of the tuning process: tuning 
contention. Contention occurs when multiple processes try to 
access the same resource simultaneously. Contention causes processes 
to wait for access. 

ORACLE provides you with methods of handling contention. In this 
chapter, you will learn how to: 

• detect contention that may affect performance 
• reduce contention 

The ORACLE resources discussed in this chapter include: 

• rollback segments 
• redo log buffer latches 
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Reducing Contention for Rollback Segments 


In this section, you will learn how to reduce contention for rollback 
segments. The following issues are discussed: 

• what rollback segments are 

• how to identify contention for rollback segments 

• how to create rollback segments 

• how to choose sizes for your rollback segments 


What Are Rollback Rollback segments are allocations of space in the database that hold 
Segments? information necessary to reverse, or undo, changes made by 

transactions. Rollback segments contain rollback entries. A single 
rollback entry contains the information necessary to undo the changes 
made by one transaction. Rollback segments are used for: 

• transaction rollback 

• read consistency 

• recovery 

Every transaction processed by the ORACLE RDBMS causes a rollback 
entry to be written to a rollback segment. The database blocks that 
make up rollback segments are accessed frequently. For this reason 
rollback segments may be subject to contention. 
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Identifying Rollback 
Segment Contention 


Examining Contention for 
Buffers 


Contention for rollback segments is reflected by contention for buffers 
that contain rollback segment blocks. Follow these steps to determine 
whether contention for rollback segments is reducing the performance 
of your RDBMS: 

1. Examine contention for buffers in the buffer cache in the System 
Global Area (SGA). 

2. Determine whether any buffer contention is due to rollback segment 
contention. 

To locate rollback segment contention, you must first examine 
contention for all buffers in the cache. ORACLE collects statistics 
reflecting this contention: 

consistent gets, The sum of these two statistics is the total number 

db block gets of requests for blocks. 

buffer busy waits The value of this statistic is the number of requests 
for buffers that result in waiting. 

These statistics are available through the SQL*DBA MONITOR 
STATISTICS CACHE display. To view the display, issue the SQL*DBA 
command: 

SQLDBA> MONITOR STATISTICS CACHE 

The SQL*DBA MONITOR STATISTICS CACHE display is made up of 
two screens. Figures 5-1 and 5-2 show these screens. In Figure 5-1, you 
can see that the first screen of the display contains the statistics 
consistent gets, db block gets, and buffer busy waits. 

Examine these statistics while your application is running. Find the 
ratio of buffer busy waits to the sum of consistent gets and db block gets. 
This ratio represents the percentage of buffer accesses that result in 
waiting. 

If the ratio is not more than 10% or 15%, then contention for any 
buffers, including those containing rollback segment blocks, is not high 
enough to reduce performance. If the ratio is more than 10% or 15%, 
then buffer contention may affect performance. In this case, you should 
determine what type of block is subject to contention by querying the 
V$WAITSTAT table as described in the next sections. 
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FIGURE >2 
SQL'DBA MONITOR 

STATISTICS CACHE Display 
(Screen 1) 


FIGURE 5-2 
SQL*DBA MONITOR 
STATISTICS CACHE Display 
(Screen 2) 


ORACLE Statistics Monitor Thu Jul 13 lli5&<39 

ORACLE PID» 0 Session s: 0 User Nane« SVSTEM STATISTICS 


Statistic NaMe 

CUR 

AUG 

MAX 

MIN 

TOT 

db block gets 

38.4b 

38.4b 

38.4b 

38.4b 

500 

consistent gets 

95.31 

95.31 

95.31 

95.31 

1Z39 

physical reads 

41.15 

41.15 

41.15 

41.15 

535 

physical urites 

9.15 

9.15 

9.15 

9.15 

119 

db block changes 

Z9. 38 

Z9.38 

Z9.38 

Z9. 38 

38Z 

change urite tine 

0.00 

a. 00 

0.00 

0.00 

0 

consistent changes 

Z. 77 

Z. 77 

Z. 77 

Z. 77 

36 

urite coriplete waits 

0.23 

0.23 

0.Z3 

0.23 

3 

urite uait tine 

0. 00 

0.00 

0.00 

0.00 

0 

buffer busy ualts 

0. 00 

0.00 

0.00 

0.00 

0 

busy uait tine 

0. 00 

0.00 

0.00 

0.00 

0 

redo synch urites 

0.69 

0.63 

0.69 

0.69 

9 

redo synch tine 

0.00 

0.00 

0.00 

0.00 

0 

DBUR exchange waits 

0.00 

0.00 

0.00 

0.00 

0 

exchange deadlocks 

0.00 

0.00 

0.00 

0.00 

0 

free buffer requeste 

45.31 

45.31 

45.31 

45.31 

589 

free buffer scans 

45.31 

45.31 

45.31 

45.31 

589 

free buffer Inspecte 

859.85 

859.85 

859.85 

859.85 

11178 

free buffer uaits 

Z. 38 

Z.3B 

2.38 

2.38 

31 

free uait tine 

0.00 

0.00 

0.00 

0.00 

0 


ORACLE Statistics Monitor Thu Jul 13 11:56:39 

ORACLE PID: e Session n: 0 User Nane: SVSTEM STATISTICS 


Statistic Nane 

CUR 

AUG 

MAX 

MIN 

TOT 

...continued (page Z) 
dbur tineouts 

0.00 

0.00 

0.00 

0.00 

0 

dbur free needed 

0.00 

0.00 

0.00 

0.00 

0 

dbur free lou 

0.54 

0.54 

0.54 

0.54 

7 

dbur buffers scanned 

10.77 

10.77 

10.77 

10.77 

140 

dbur checkpoints 

0. 00 

0.00 

0.00 

0.00 

0 

consistent forceouts 

0.00 

0.00 

0.00 

0.00 

0 
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The Dynamic 
Performance 
V$WAITSTAT Table 


Block contention statistics are kept in the dynamic performance table 
SYS.V$WAITSTAT. These statistics reflect block contention since the 
most recent database startup. Columns of the V$WAITSTAT table are: 


OPERATION 

This column identifies the type of operation 
causing the contention. Values for this 
column are: 

buffer busy waits 

Rows with this value reflect contention for 
buffers. 

consistent lock gets, 
current lock gets 

Rows with these values are only used for 
multi-instance ORACLE. 

CLASS 

This column identifies the class of block 
subject to contention. Values for this column 
are: 

undo segment 
header 

Rows with this value reflect contention for 
buffers containing rollback segment header 
blocks. 

undo block 

Rows with this value reflect contention for 
buffers containing rollback segment blocks 
other than header blocks. 

data block 

Rows with this value reflect contention for 
buffers containing data blocks. 

segment header, 
save undo block, 
save undo header, 
sort block 

Rows with these values are not useful for 
tuning. 

RANGE 

This column specifies a range of waiting time. 
Values for this column are expressed in 
milliseconds. Values for this column are: 

0-30 

30-100 

100-500 

500-1000 

1000-2000 

2000-4000 

>4000 
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COUNT 


The value in this column is the number of waits by 
the particular OPERATION for the particular 
CLASS of block lasting for the particular RANGE 
of time. 

The value in this column is the sum of all the wait 
times for all the waits by the particular 
OPERATION for the particular CLASS of block 
lasting for the particular RANGE of time. 


Querying V$W AITSTAT 


To get a better idea which CLASS of block is subject to contention, 
group the rows of the V$WAITSTAT table by the CLASS column. You 
can determine the total number of waits for each CLASS of block with 
this query: 

SELECT CLASS, SUM(COUNT) TOTAL_WAITS 
FROM SYS.V$WAITSTAT 

WHERE OPERATION = 'buffer busy waits' 

AND CLASS IN ('undo segment header', 'undo block', 'data block') 
GROUP BY CLASS 


The result of this query might look like this: 


CLASS TOTAL_WAITS 

undo segment header 1235 

undo block 942 

data block 5 

where: 


class is the CLASS of block subject to contention. 

total waits is the total number of waits for the particular 

CLASS of block. 

Examining the sample query output leads to these observations: 

• There were a total of 1235 waits for buffers containing rollback 
segment header blocks. 

• There were a total of 942 waits for buffers containing rollback 
segment blocks other than header blocks. 

• There were a total of 5 waits for buffers containing data blocks. 

The sample query output indicates that a relatively large portion of the 
contention reflected by the buffer busy waits statistic is for buffers 
containing rollback segment blocks. A relatively small portion of this 
contention is for buffers containing data blocks. 
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Reducing Contention for 
Buffers 


Creating Rollback 
Segments 


Choosing Sizes for 
Rollback Segments 


To reduce the contention reflected by the buffer busy waits statistic, 
reduce contention for the CLASS of block with the most 
TOTAL_WAITS: 

• If most of the contention is for buffers containing either 
rollback segment header blocks or other rollback segment 
blocks, as in the example in the previous section, reduce 
contention by creating more rollback segments. 

• If most of the contention is for buffers containing data blocks, 
refer to Chapter 6 "Additional Tuning Considerations." 


To reduce contention for buffers containing rollback segment blocks, 
create more rollback segments. The following are some general 
guidelines for choosing how many rollback segments to allocate based 
on the number of concurrent transactions on your RDBMS. These 
guidelines are appropriate for most application mixes: 


Number of Concurrent Recommended Number 

Transactions of Rollback Segments 

fewer than 16 4 segments 

16 to 32 8 segments 

32 or more n/4 but not more than 50 

To create rollback segments, use the CREATE ROLLBACK SEGMENT 
statement. For more information on this statement, refer to the 
SQL Language Reference Manual. 


The size of your rollback segments can also affect performance. 
Rollback segment size is determined by storage parameters in the 
CREATE ROLLBACK SEGMENT statement. Your rollback segments 
must be large enough to hold the rollback entries for your transactions. 

Be sure all of your rollback segments are the same size. Creating a 
single large rollback segment does not guarantee that large rollback 
entries will not cause extension. Since transactions are assigned to 
rollback segments randomly, you cannot be sure that a particularly 
large transaction will be assigned to a large rollback segment rather 
than to a smaller one. 
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For Long Queries and 
Long Transactions 


For OLTP Applications 


Some applications perform long queries on data that is being modified 
concurrently by other transactions. Such queries may require access to 
rollback segments to reconstruct a read-constslen^ version oi 
modified data. These rollback segments must be large enough to hold 
all the rollback entries for the data while the query is running. 

Urge rollback segments can also improve the performance of single 
transactions that modify large amounts of data. Such transactions 
generate large rollback entries If a onfrir Hnno nnf (it- i m-* 

rollback segment, ORACLE extends the segment. Dynamic extension 
reduces performance and should bo avoided whenever possible. 

Some applications perform online transaction processing , or OLTP. OLTP 
applications are characterized by frequent concurrent transactions that 
each modify small amounts of data. If your application performs only 
OLTP with no long queries or long transactions, you can improve 
performance by creating many small rollback segments. It may help to 
have as many rollback segments as concurrent transactions. Each 
transaction can then access a separate rollback segment with no risk of 
contention. 

Small rollback segments are more likely to remain stored in the buffer 
cache where they can be accessed quickly. A typical OLTP rollback 
segment might have 2 extents, each on the order of 10 kilobytes in size. 
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Reducing Contention for Redo Log Buffer Latches 

Contention for redo log buffer access rarely inhibits database 
performance. However, ORACLE provides you with methods to 
monitor and reduce any latch contention that does occur. This section 
explains: 

• what the redo log buffer is 

• what the redo log buffer latches do 

• how to detect contention for latches 

• how to reduce contention for latches 


The Redo Log Buffer The redo log buffer is a circular buffer in the SGA that holds information 

about changes made to the database. This information is stored in redo 
entries. Redo entries contain the information necessary to reconstruct, 
or redo, changes made to the database by Data Manipulation Language 
(DML) operations (INSERT, UPDATE, or DELETE) or Data Definition 
Language (DDL) operations (CREATE, ALTER, or DROP). Redo 
entries are used for database recovery. 

Redo entries are copied by ORACLE user processes from the user's 
memory space to the redo log buffer in the SGA. The redo entries take 
up continuous, sequential space in the buffer. 

The redo log buffer is written to a redo log file on disk by the Log Writer 
process (LGWR), an ORACLE background process responsible for redo 
log buffer management. The LGWR process writes all the redo entries 
that have been copied into the buffer since the last time it wrote. 

LGWR writes one contiguous portion of the buffer to disk. LGWR 
writes: 


The Log Writer Process 
(LGWR) 


• when a user process commits a transaction 

• when the redo log buffer is one-third full 

• when the DBWR process writes modified buffers to disk 
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Space in the Redo Log 
Buffer 


FIGURE 5-3 
SQL*DBA MONITOR 
STATISTICS REDO Display 


When LGWR writes redo entries from the redo log buffer to a redo log 
file, user processes can then copy new entries over the entries that have 
been written to disk. LGWR normally writes fast enough to ensure that 
space is always available in the buffer for new entries, even when 
access to the redo log is heavy. 

The statistic redo log space requests reflects the number of times a user 
process waits for space in the redo log buffer. You can monitor this 
statistic through the SQL*DBA MONITOR STATISTICS REDO display. 

Figure 5-3 shows this display. To view foe display, issue foe SQl 
command: 

SQLDBA> MONITOR STATISTICS REDO 

The value of redo log space requests should always be 0. A non-zero 
value indicates that processes are waiting for space in the buffer. In 
this case, increase the size of the redo log buffer. The size of the redo 
log buffer is determined by the INIT.ORA parameter LOG_BUFFER. 
The value of this parameter is expressed in bytes. 

In Figure 5-3, you can see the value of the redo log space requests statistic 
is 0. 



ORACLE 

Statistics Monitor 

Thu 

Jun 22 14:22:33 

ORACLE PID: 0 

Session 

»: 0 

User Name: 

SYSTEM STATISTICS 

Statistic Nane 

CUR 

AUG 

MAX 

MIN 

TOT 

redo entries 

11.33 

11.33 

11.33 

11.33 

60 

redo size 

2203.67 2283.67 

2203.67 

2203.67 

13702 

redo entries 1ineari 

0.00 

0.00 

0.00 

0.00 

0 

redo buffer allocati 

0.00 

0.00 

0.00 

0.00 

0 

redo snail copies 

11.17 

11.17 

11.17 

11.17 

67 

redo uastage 

155.17 

155.17 

155.17 

155.17 

931 

redo uriter latching 

0.00 

0.00 

0.00 

0.00 

0 

redo urites 

0.50 

0.50 

0.50 

0.50 

3 

redo blocks uritten 

5. 17 

5.17 

5.17 

5. 17 

31 

redo urite tine 

0.00 

0.00 

0.00 

0.00 

0 

redo log suitch uait 

0.00 

0.00 

0.00 

0.00 

0 

redo chunk allocatio 

0.00 

0.00 

0.00 

0.00 

0 

redo log space regue 

0. 00 

0.00 

0.00 

0.00 

0 

redo log space uait 

0.00 

0.00 

0.00 

0.00 

0 

redo log suitch inte 

0. 00 

0.00 

0.00 

0.00 

0 
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Redo Log Buffer 
Latches 


The Redo Allocation Latch 


Redo Copy Latches 


Access to the redo log buffer is regulated by latches. Two types of 
latches control access to the redo log buffer: 

• tine redo allocation \a\ch 

• redo copy latches 

The redo allocation latch controls the allocation of space for redo entries 
in the redo log buffer. To allocate space in the buffer, an ORACLE user 
process must obtain the redo allocation latch. Since there is only one 
redo allocation latch, only one user process can allocate space in the 
buffer at a time. The single redo allocation latch enforces the sequential 
nature of the entries in the buffer. 

After allocating space for a redo entry, the user process may copy the 
entry into the buffer while holding the redo allocation latch. Such a 
copy is referred to as "copying on the redo allocation latch." A process 
may only copy on the redo allocation latch if the redo entry is smaller 
than a threshold size. After copying on the redo allocation latch, the 
user process releases the latch. 

The maximum size of a redo entry that can be copied on the redo 
allocation latch is specified by the INIT.ORA parameter 
LOG_SMALL_ENTRY_MAX_SIZE. The value of this parameter is 
expressed in bytes. The default value depends on your operating 
system. 

If the redo entry is too large to copy on the redo allocation latch, the 
user process must obtain a redo copy latch before copying the entry into 
the buffer. While holding a redo copy latch, the user process copies the 
redo entry into its allocated space in the buffer and then releases the 
redo copy latch. 

If your computer has multiple CPUs, your redo log buffer can have 
multiple redo copy latches. Multiple redo copy latches allow multiple 
processes to copy entries to the redo log buffer concurrently. The 
number of redo copy latches is determined by the INIT.ORA parameter 
LOG_SIMULTANEOUS_COPIES. The default value of 
LOG_SIMULTANEOUS_COPIES is tne value of the INIT.ORA 
parameter CPU_COUNT. ORACLE automatically sets the value of 
CPU_COUNT to the number of CPUs available to your ORACLE 
instance. 

On single-CPU computers, there should be no redo copy latches, since 
only one process can by active at once. In this case, all redo entries are 
copied on the redo allocation latch, regardless of size. ORACLE sets 
the value of CPU_COUNT to 0. 
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Examining Redo Log 
Activity 


FIGURE 5-4 

SQL*DBA MONITOR LATCH 
Display 


Heavy access to the redo log buffer can result in contention for redo log 
buffer latches. Latch coutetvtiou cab pgSfotMWCfc. QMQ& 
collects statistics for the activity of all latches. Examine the activity of 
the redo log buffer latches in the SQL*DBA MONITOR LATCH 
display. Figure 5-4 shows this display. To view this display, issue the 
SQL*DBA command: 

SQLDBA> MONITOR LATCH 

Examine the statistics for the redo allocation latch and the redo copy 
latches. Note the statistics for the Willing to Wait Requests: 

Total The value of this statistic is the total number of 

requests for the latch. 

Timeouts The value of this statistic is the number of timeouts 

while waiting for the latch. A timeout results from 
an unsuccessful request for a latch. The amount of 
wait time and the number of requests before a 
timeout depends upon your operating system. 

If the ratio of Timeouts to Total for a particular latch exceeds a threshold 
of 10% or 15%, then contention for that latch may be affecting 
performance. In this case, reduce contention for the latch. 

The contention threshold is appropriate for most operating systems, 
though some computers with many CPUs may be able to tolerate more 
contention without performance reduction. Refer to your Installation 
and User's Guide for more information specific to your operating system. 


ORACLE Latch Monitor Thu Jun ZZ 14:Z0:57 

Holder -Ui11ing-to-Uait-Requests —No-Uait-Requests— 


Latch Mane 

PID 

Total 

Timeouts 

I mediates 

Total 

Successes 

process allocation 


659 

48 

646 

0 

0 

session allocation 


Z3789 

Z4 

Z3767 

0 

0 

Messages 


5346Z 

359 

53110 

0 

0 

enqueues 


61033 

178 

61665 

0 

0 

cache buffers chains 


100O9Z6 

707 

100OZ59 

11Z5GG 

11Z477 

cache buffers lru ch 


00730 

773 

80019 

354631 

35Z1G9 

cache buffer handles 


348 

1 

347 

0 

0 

Multiblock read obje 


10904 

0 

10904 

0 

0 

inter-instance buffe 


e 

0 

0 

0 

0 

system commit number 


56510 

33 

56478 

0 

0 

archive control 


0 

0 

0 

0 

0 

redo allocation 


55567 

919 

54660 

0 

0 

redo copy 


0 

0 

0 

Z1547 

Z1547 

dml/ddl allocation 


19Z5S 

13 

19Z43 

0 

0 

transaction allocati 


6597 

1 

6596 

0 

0 

undo global data 


6Z77 

0 

6Z77 

0 

0 

sequence cache 


1585 

4 

1581 

0 

0 

rou cache objects 


1Z8948 

633 

1Z8641 

0 

0 
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Reducing Latch 
Contention 


Reducing Contention for 
the Redo Allocation Latch 


Reducing Contention for 
Redo Copy Latches 


Most cases of latch contention occur when two or mbre ORXQJ&, 
processes concurrently attempt to obtain the same latch. Latch 
contention rarely occurs on single-CPU computers where only a single 
process can be active at once. 

To reduce contention for the redo allocation latch, you should minimize 
the time that any single process holds the latch. To reduce this time, 
reduce copying on the redo allocation latch. Decreasing the value of 
the INIT.ORA parameter LOG_SMALL_ENTRY_M AX_SIZE reduces 
the number and size of redo entries copied on the redo allocation latch. 

On multiple-CPU computers, multiple redo copy latches allow multiple 
processes to copy entries to the redo log buffer concurrently. The 
default value of LOG_SIMULTANEOUS_COPIES is the value of the 
INIT.ORA parameter CPU_COUNT. ORACLE automatically sets the 
value of CPU_COUNT to the number of CPUs available to your 
ORACLE instance. On single-CPU computers, ORACLE sets the value 
of CPU_COUNT to 0. 

If you observe contention for redo copy latches, add more latches. To 
increase the number of redo copy latches, increase the value of 
LOG_SIMULTANEOUS_COPIES. It can help to have up to twice as 
many redo copy latches as CPUs available to your ORACLE instance. 

Another way to reduce contention for redo copy latches is to reduce the 
time each process holds a latch. You can reduce this time by forcing the 
ORACLE user process to "pre-build" redo entries before obtaining a 
redo copy latch. 

A redo entry may consist of many pieces. Usually each piece of a redo 
entry is copied individually from the user process memory into the 
redo log buffer while a redo copy latch is held. Copying the pieces of a 
redo entry individually requires many writes to memory. However, 
when an entry is "pre-built," the user process assembles all the pieces 
together before requesting the latch. The redo entry can then be copied 
to the buffer in a single write to memory. 

User processes pre-build all entries that are smaller than a threshold 
size. This threshold size is determined by the INIT.ORA parameter 
LOG_ENTRY_PREBUILD_THRESHOLD. The value of this parameter 
is expressed in bytes. The default value is 0. This value means that the 
default behavior is to not pre-build any entries. 

To force your user processes to pre-build more of their redo entries, 
increase LOG_ENTRY_PREBUILD_THRESHOLD. 
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ning All ORACLE Processes Equal Priority 


Many processes are involved in the operation of the ORACLE RDBMS. 
These processes all access the shared memory resources in the SGA. 


Be sure that all ORACLE processes, both background processes ana 
user processes, have the same process priority. When you install 
ORACLE, all background processes are given the default priority for 
your operating system. You should not change the priorities of 
background processes. You should also be sure that all user processes 
have the default operating system priority. 

Assigning different priorities to ORACLE processes may exacerbate the 
effects of contention. Your operating system may not grant processing 
time to a low priority process if a high priority process also requests 
processing time. If a high priority process needs access to a memory 
resource held by a low priority process, the high priority process may 
wait indefinitely for the low priority process to obtain the CPU, 
process, and release the resource. 




ORACLE RDBMS Performance Tuning Guide 


T 












CHAPTER 


Additional 

Tuning 

Considerations 


T his chapter discusses additional tuning measures you should 
undertake after completing the steps presented in the first five 
chapters of this Guide. These measures tune very specific operations of 
the ORACLE RDBMS. Nevertheless, these measures may be important 
if these operations are reducing performance. The topics covered by 
this chapter include: 

• sorts 
• free lists 
• checkpoints 
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Tuning 


Sorts 


Causes of Sorting 


Some applications cause ORACLE to sort data. This section tells you: 

• when ORACLE sorts data 

• what memory is required to sort data 

• how to allocate memory to optimize your sorts 

• how to avoid sorting when creating indexes 

These SQL statements cause ORACLE to sort data: 

• SQL statements that create indexes 

• SQL statements that have GROUP BY or ORDER BY clauses 

• SQL statements that use the DISTINCT operator 

• SQL statements that perform joins 

• SQL statements that use the UNION, INTERSECT, or MINUS 
set operators 


Sorting requires space in memory. Portions of memory in which 
ORACLE sorts data are referred to as sort areas. A sort area exists in the 
memory of an ORACLE user process that requests a sort. The size of a 
sort area is determined by the INIT.ORA parameter 
SORTARE A_SIZE. The value of this parameter is expressed in bytes. 

If the amount of data to be sorted does not fit into the allocated sort 
area, then the data is divided into smaller pieces that do fit into the sort 
area. Each piece is then sorted individually. The individual sorted 
pieces are referred to as "runs." After sorting all the runs, ORACLE 
merges them to produce the final result. 

After sorting a run, ORACLE stores it in a temporary segment on disk 
while subsequent runs are sorted. By default, temporary segments are 
created in the SYSTEM tablespace. Another tablespace can be specified 
as the default with the TEMPORARY TABLESPACE clause of the 
ALTER USER statement. For example: 

ALTER USER KING 

IDENTIFIED BY ARTHUR 
TEMPORARY TABLESPACE CAMELOT 

The INIT.ORA parameter SORT_SPACEMAP_SIZE determines how 
ORACLE manages the spacemap for intermediate runs. ORACLE 
automatically adjusts this parameter. You should not change it. 
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Allocating Memory for 
Sort Areas 


Recognizing Large Sorts 


Increasing Sort Area Size 


Performance Benefits of 
Large Sort Areas 


Performance Tradeoffs for 
Large Sort Areas 


The default sort area size is adequate to hold all the data for most sorts. 
However, if your application often performs large sorts on data that 
does not fit into the sort area, then you may want to increase the sort 
area size. Large sorts can be caused by the creation of large indexes or 
by SQL statements with GROUP BY clauses that process large numbers 
of rows. 

You can determine whether your sort area is too small. Use the ALTER 
USER statement to specify the temporary tablespace for the user 
process performing the sort. Then monitor the disk I/O to that 
tablespace during the sort. You can monitor disk I/O through the 
SQL*DBA MONITOR FILE I/O display. To view the display, issue the 
SQL*DBA command: 

SQLDBA> MONITOR FILE 

If I/O to the temporary tablespace during the sort is excessive, then 
your application's performance may benefit from increasing the size of 
the sort area. In this case, increase the value of the INIT.ORA 
parameter SORT_ARE A_SIZE. 

Increasing the size of the sort area increases the size of each run and 
decreases the total number of runs. This decrease can improve 
performance in two ways: 

• Reducing the total number of runs reduces the number of 
merges ORACLE must perform to obtain the final sorted result. 

• Reducing the total number of runs reduces the disk I/O to the 
temporary segment necessary to perform the sort. 

Increasing the size of the sort area causes each ORACLE process that 
sorts to allocate more memory. This increase reduces the amount of 
memory available for context areas. It can also affect operating system 
memory allocation and may induce paging and swapping. Before 
increasing the size of the sort area, be sure enough free memory is 
available on your operating system to accommodate a larger sort area. 
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Avoiding Sorts 


The NOSORT Option 


Choosing When to Use the 
NOSORT Option 


One cause of sorting is the creation of indexes. Creating an index for a 
table involves sorting all the rows in the table based on the values of 
the indexed column or columns. 

ORACLE also allows you to create indexes without sorting. If the rows 
in the table are loaded in ascending order, you can create the index 
faster without sorting. 

To create an index without sorting, load the rows into the table in 
ascending order of the indexed column values. Your operating system 
may provide you with a sorting utility to sort the rows before you load 
them. 

When you create the index, use the NOSORT option on the CREATE 
INDEX statement. For example, this CREATE INDEX statement creates 
the index EMP_INDEX on the ENAME column of the EMP table 
without sorting the rows in the EMP table: 

CREATE INDEX EMP_INDEX ON EMP(ENAME) NOSORT 

Presorting your data and loading it in order may not always be the 
fastest way to load a table. If you have a multiple-CPU computer, you 
may be able to load data faster using multiple processors in parallel, 
each processor loading a different portion of the data. To take 
advantage of parallel processing, load the data without sorting it first. 
Then create the index without the NOSORT option. 

On the other hand, if you have a single-CPU computer, you should sort 
your data before loading, if possible. Then you should create the index 
with the NOSORT option. 
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Reducing Free List Contention 

Free list contention can reduce the performance of some applications. 
This section tells you: 

• what free lists are 

• how to identify contention for free lists 

• how to increase the number of free lists 

Free Lists A free list is a list of data blocks that contain free space. Free lists are 

used to keep track of blocks that have enough free space to accept new 
rows. 

Every table has one or more free lists. The number of free lists for each 
table is determined by the value of the INIT.ORA parameter 
FREE_LIST_PROC at the time the table is created. The default value for 
this parameter is 4. 

When an ORACLE process inserts a row into a table, the process must 
first find a data block with free space to hold the row. To find such a 
block, the process searches one of the table's free lists. 

Contention for free lists may occur if many ORACLE processes 
concurrently insert rows into the same table. Each process must access 
a free list. If there are fewer free lists than processes, some of the 
processes may have to wait for a free list. 
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Identifying Free List 
Contention 


Examining Buffer 

Contention 


Contention for free lists is reflected by contention for data blocks in the 
buffer cache. Follow these steps to determine whether contention for 
free lists is reducing the performance of your RDBMS. 

1. Examine contention for buffers in the buffer cache in the System 
Global Area (SGA). 

2. Determine whether any butter contention is due to treeiist contention. 

To locate free list contention, you must first examine contention for all 
blocks in the buffer cache. ORACLE collects tftese statistics that reflect 
contention for buffers in the buffer cache: 

consistent gets. The sum of these two statistics is the total number 

db block gets of requests for data blocks. 

buffer busy waits The value of this statistic is the number of requests 
for buffers that result in waiting. 

These statistics are available through the SQL*DBA MONITOR 
STATISTICS CACHE display. To view the display, issue the SQL*DBA 
command: 

SQLDBA> MONITOR STATISTICS CACHE 

The SQL*DBA MONITOR STATISTICS CACHE display is made up of 
two screens. Figures 6-1 and 6-2 show these screens. In Figure 6-1, you 
can see that the first screen of the display contains the statistics 
consistent gets, db block gets, and buffer busy waits. 

Examine these statistics while your application is running. Find the 
ratio of buffer busy waits to the sum of consistent gets and db block gets. 

This ratio represents the percentage of buffer accesses that result in 
waiting. 

If the ratio is no more than 10% or 15%, then contention for any buffers, 
including those containing data blocks, is not high enough to reduce 
performance. If the ratio is much more than 10% or 15%, then 
contention may be affecting performance. In this case, you should 
determine what type of block is the subject of the contention. 
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FIGURE 6-1 
SQL*DBA MONITOR 
STATISTICS CACHE Display 
(Screen 1) 


FIGURE 6-2 
SQL*DBA MONITOR 
STATISTICS CACHE Display 
(Screen 2) 


ORACLE Statistics Monitor Thu Jul 13 11*56:35 

ORACLE PID* 0 Session a: 0 User Mane* SVSTEM STATISTICS 


Statistic NaMe 

CUR 

AUG 

MAX 

MIN 

TOT 

db block gets 

38.46 

38.46 

38.46 

38.46 

500 

consistent gets 

35.31 

55.31 

95.31 

95.31 

1Z39 

physical reads 

41.15 

41.15 

41.15 

41.15 

535 

physical urites 

9. 15 

9.15 

9.15 

9. 15 

119 

db block changes 

Z9.38 

Z9.3B 

Z9.38 

Z9. 38 

38Z 

change urite tine 

0.00 

0.00 

0.00 

0.00 

0 

consistent changes 

Z. 77 

Z. 77 

Z.77 

Z.77 

36 

urite conplete uaits 

0.Z3 

0.23 

0.Z3 

0.23 

3 

urite uait tine 

0.00 

0.00 

0.00 

0.00 

0 

buffer busy uaits 

0.00 

0.00 

0.00 

0. 00 

0 

busy uait tlMe 

0.00 

0.00 

0.00 

0.00 

0 

redo synch urites 

0.69 

0.69 

0.69 

0.69 

9 

redo synch tine 

0.00 

0.00 

0.00 

0.00 

0 

DBUR exchange uaits 

0.00 

0.00 

0.00 

0.00 

0 

exchange deadlocks 

0.00 

0.00 

0.00 

0.00 

0 

free buffer requeste 

45.31 

45.31 

45.31 

45. 31 

589 

free buffer scans 

45.31 

45.31 

45.31 

45.31 

589 

free buffer inspecte 

859.85 

859.85 

859.85 

859.85 

11178 

free buffer uaits 

Z. 38 

Z. 38 

Z. 38 

Z. 38 

31 

free uait tine 

0. 00 

0.00 

0.00 

0.00 

0 


ORACLE Statistics Monitor Thu Jul 13 11*56*35 

ORACLE PID* e Session a: 0 User Mane* SYSTEM STATISTICS 


Statistic Nane 

CUR 

AUG 

MAX 

MIN 

TOT 

...continued (page Z> 
dbur timeouts 

0. 00 

0.00 

0.00 

0.00 

0 

dbur free needed 

0.00 

0.00 

0.00 

0.00 

0 

dbur free lou 

0.54 

0.54 

0.54 

0.54 

7 

dbur buffers scanned 

10.77 

10.77 

10.77 

10.77 

140 

dbur checkpoints 

0.00 

0.00 

0.00 

0.00 

0 

consistent forceouts 

0.00 

0.00 

0.00 

0.00 

0 


Additional Tuning Considerations 


6-7 

















The V$W AITSTAT Table 


Querying the 
V$WAITSTAT Table 


ORACLE collects statistics for each type of block subject to contention. 
These statistics are kept in the dynamic performance table 
SYS.vsw AITSTAT. The columns of live MIST AT \Mt W, 

QRERA TJCW 'Thiff €vJcr#rt#t 

causing the contention. 

CLASS This column identifies the class of block subject to 

contention. 

COUNT The value in this column is the number of waits for 

the class of block identified in the CLASS column. 
This number accumulates beginning at database 
startup. 

To get a better idea which CLASS of block is subject to the most 
contention, group the rows of the V$WAITSTAT table by the CLASS 
column. You can determine the total number of waits for each CLASS 
of block with this query: 

SELECT CLASS, SUM(COUNT) TOTAL_WAITS 
FROM SYS.V3WAITSTAT 

WHERE OPERATION = 'buffer busy waits' 

AND CLASS IN ('data block', 'undo segment header', 'undo block') 
GROUP BY CLASS 

The result of this query might look like this: 

CLASS TOTAL_WAITS 

data block 755 

undo block 10 

undo segment header 8 

where: 

class is the CLASS of block subject to contention. 

total waits is the total number of waits for a particular CLASS 

of block. 

Examining the sample query output leads to these observations: 

• There were a total of 755 waits for buffers containing data 
blocks. 

• There were a total of 10 waits for buffers containing rollback 
segment header blocks. 

• There were a total of 8 for buffers containing rollback segment 
blocks other than header blocks. 
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The sample query output indicates that a relatively large portion of the 
contention reflected by the buffer busy waits statistic is for buffers 
containing data blocks. A relatively small portion of this contention is 
for buffers containing rollback segment blocks. 

Reducing Buffer To reduce the contention reflected by the buffer busy waits statistic. 

Contention reduce contention for the CLASS of block with the most 

TOT AL_W AITS: 

• If most of the contention is for buffers containing data blocks, 
as in the example in the previous sections, reduce contention 
by adding more free lists. 

• If most of the contention is for buffers containing either 
rollback segment header blocks or other rollback segment 
blocks, refer to Chapter 5 'Tuning Contention." 


Adding More Free Lists Follow these steps to reduce free list contention: 

1. Shut down ORACLE. 

2. Increase the value of the INIT.ORA parameter FREE_LIST_PROC to 
the number of ORACLE processes that concurrently access the 
database, but not more than 32. 

3. Restart ORACLE. 

4. Recreate the table whose free lists were subject to contention. 

Recreating the table may simply involve dropping and recreating 
it. However, you may want to recreate the table by selecting data 
from the old table into a new table, dropping the old table, and 
renaming the new one. 

The new table will have as many free lists as are specified by the 
INIT.ORA parameter FREE_LIST_PROC. 
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Tuning Checkpoints 


The Purpose of 
Checkpoints 


For Recovery 


For Redo Log Maintenance 


A checkpoint is an operation performed automatically by the ORACLE 
RDBMS. Checkpoints can momentarily reduce performance. This 
section tells you: 

• why ORACLE performs checkpoints 

• when ORACLE performs checkpoints 

• how ORACLE performs checkpoints 

• how checkpoints affect performance 

• how to change the frequency of checkpoints 

• how to choose the frequency of checkpoints 

Checkpoints serve these purposes: 

• to provide a time from which to roll forward for recovery in 
the event of an ORACLE instance failure 

• to allow a full redo log file to be reused or archived 

For example, if your computer experiences a power failure, most data 
can be found in the database files on disk. However, some modified 
blocks in the buffer cache may not have been written to the database 
files before the failure. The committed changes to these blocks are 
protected by redo entries in the redo log file on disk. You can recover 
all data up to the point of the failure by applying the changes specified 
in the redo entries. This process is called rolling forward. A checkpoint 
ensures that all modified blocks are written to the database files, 
establishing a time from which ORACLE can roll forward. 

Checkpoints also allow redo log files to be reused or achieved. 

ORACLE requires at least 2 redo log files. The Log Writer process 
(LGWR) writes all redo entries sequentially to a single redo log file 
until that file is full. LGWR then continues writing entries to another 
redo log file. The point at which a redo log file is full and LGWR 
begins writing to another file is called a log switch. 

A checkpoint always occurs on a log switch. This checkpoint 
guarantees that all the changes protected by the previous redo log file 
are written to the database files and the redo entries are no longer 
needed. The previous file can then be either reused or archived. For 
information on archiving, refer to Chapter 15 "Database Backup and 
Recovery" in the ORACLE RDBMS Database Administrator's Guide. 
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The Occurrence of 
Checkpoints 


How ORACLE 
Performs Checkpoints 


A checkpoint occurs under these circumstances: 

• when a redo log file is filled 

• when LGWR has written a specified number of blocks since the 
previous checkpoint 

Checkpoints always occur on log switches, as described in the previous 
section. 

Checkpoints may also occur between log switches. A checkpoint 
occurs when LGWR has written a specified number of blocks in the 
redo log file since the previous checkpoint. The number of blocks 
written between each checkpoint is called the checkpoint interval. The 
checkpoint interval is specified by the INIT.ORA parameter 
LOG JZHECKPOINTJNTERVAL. The value of this parameter is 
expressed in operating system blocks rather than ORACLE blocks. 

For example, if your redo log files are of size 5000 blocks and the value 
of LOG_CHECKPOINT_INTERVAL is 2000 blocks, ORACLE performs 
3 checkpoints for each redo log file. The first checkpoint occurs when 
LGWR writes the first 2000 blocks to the file. The second checkpoint 
occurs when LGWR writes another 2000 blocks so that 4000 blocks have 
been written. The third checkpoint occurs when LGWR writes another 
1000 blocks, filling the file and causing a log switch. 


When a checkpoint occurs, LGWR makes a list of the blocks in the buffer 
cache that have been modified since the previous checkpoint, but have 
not yet been written to database files. The Database Writer process 
(DBWR) then writes these blocks to database files. When DBWR 
finishes writing, the checkpoint is complete. 
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Checkpoints affect: 

• recovery time performance 

• runtime performance 

Frequent checkpoints can reduce recovery time in the event of an 
instance failure. If the checkpoint interval is small, then relatively few 
changes to the database can be made between checkpoints. In this case, 
relatively few changes must be rolled forward for recovery. 

Since checkpoints cause DBWR to perform I/O, a checkpoint can 
momentarily reduce runtime performance. The overhead associated 
with a checkpoint is usually small and only affects performance while 
ORACLE performs the checkpoint. 

Changing Checkpoint You can change the frequency of checkpoints performed by your 
Frequency RDBMS by changing the checkpoint interval. Increasing the checkpoint 

interval reduces checkpoint frequency. Reducing the checkpoint 
interval increases checkpoint frequency. To change the checkpoint 
interval, change the value of the INIT.ORA parameter 
LOG_CHECKPOINT_INTERV AL. 

Because checkpoints on log switches are necessary for redo log 
maintenance, you cannot eliminate checkpoints entirely. However, you 
can reduce checkpoints to a minimum by setting 
LOG_CHECKPOINT_INTERVAL to a value larger than the size of 
your largest redo log file. Such a setting eliminates all checkpoints 
except those that occur on log switches. 

You can further reduce checkpoints by reducing the frequency of log 
switches. To reduce log switches, increase the size of your redo log 
files so that the files do not fill as quickly. 

Choosing Checkpoint You should choose a checkpoint frequency for your RDBMS based on 
Frequency your performance concerns. If you are more concerned with efficient 

runtime performance than recovery time, choose a lower checkpoint 
frequency. If you are more concerned with fast recovery time than 
runtime performance, choose a higher checkpoint frequency. 


How Checkpoints 
Affect Performance 


Recovery Time 
Performance 


Runtime Performance 
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Performance 
Diagnostic Tools 

T he primary tool for monitoring the performance of the ORACLE 
RDBMS is SQL*DBA. The SQL*DBA MONITOR displays are 
documented in Appendix B "The SQL*DBA Reference" of the ORACLE 
RDBMS Database Administrator's Guide. 

Additional performance tools are described in this chapter. These tools 
and the SQL*DBA MONITOR displays can help you monitor and tune 
applications that run against the RDBMS. 

The performance tools described in this chapter are: 

• the SQL trace facility 
• the EXPLAIN PLAN statement 

The output of the EXPLAIN PLAN statement depends upon the 
ORACLE optimizer. Because the ORACLE optimizer is subject to 
change between releases of the ORACLE RDBMS, output from the 
EXPLAIN PLAN statement will evolve. In future releases, output may 
differ substantially from the current version. Similarly, the SQL trace 
facility and TKPROF program are subject to significant change in future 
releases of ORACLE. These changes will be documented for users of 
these facilities. 
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The SQL Trace Facility 


c SQL trace facility provides performance information on individual 
oQL statements. The SQL trace facility generates the following 
statistics for each statement'. 


• parse, execute, and fetch counts 

• CPU and elapsed times 

• physical reads and logical reads 

• number of rows processed 

You can enable the SQL trace facility for a session or for an instance. 
When the SQL trace facility is enabled, performance statistics for all 
SQL statements executed in a user session or in an instance are placed 
into a trace file. To translate the trace file into readable form, you can 
run the TKPROF program. 

As an option, TKPROF also displays the execution plan of a SQL 
statement. You can specify this with the EXPLAIN argument on the 
TKPROF command line. For syntax of the TKPROF command, see the 
section Running TKPROF" in this chapter. For additional information 
on the EXPLAIN PLAN statement, refer to the section "The EXPLAIN 
PLAN Statement" in this chapter. 

Because running the SQL trace facility increases system overhead, you 
should enable it only when examining your SQL statements, and 
disable it when you are done. 

To use the SQL trace facility, follow these steps: 

1. Set INIT.ORA parameters to prepare ORACLE for using the SQL 
trace facility. 

2. Run the application with tracing enabled for the session or the 
instance. 

3. Use TKPROF to report the statistics in readable form. 

Each of these steps is discussed in detail below. 
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Setting INIT.ORA 
Parameters for the SQL 
Trace Facility 


Enabling Tracing for a 
Session 


Before running your application with the SQL trace facility enabled, 
start the ORACLE instance with the following INIT.ORA parameter 
settings: 


• TIMED_STATISTICS = TRUE 

This enables timing offered by the SQL trace facility, such as 
CPU and elapsed times. Enabling TIMED_STATISTICS causes 
extra timing calls for low-level operations. This parameter also 
enables the collection of certain statistics in the SQL*DBA 
MONITOR displays. 

• MAX_DUMP_FILE_SIZE = n 

You should determine the maximum number of operating 
system blocks for holding the trace output. If you find that 
your output is truncated, increase the number of blocks 
specified by this parameter and start the trace again. 

• USER_DUMP_DEST = directory 

The trace file is written to the default directory for system 
dumps. If you want to change the destination, consult your 
Installation and User's Guide for the correct method of naming 
another directory. 

To enable the SQL trace facility for an individual session, issue the SQL 
statement: 

ALTER SESSION SET SQL_TRACE TRUE 

To turn off the SQL trace facility, issue the SQL statement: 

ALTER SESSION SET SQL_TRACE FALSE 

The SQL trace facility also turns off automatically when your 
application disconnects from ORACLE. 

You may need to modify your application to contain the ALTER 
SESSION statement. For example, to issue the ALTER SESSION 
command in SQL*Forms Version 3.0, invoke SQL*Forms using the -s 
option, or invoke SQL*Forms (Design) using the statistics option. For 
more information on SQL*Forms, refer to the SQL*Forms Designer's 
Reference. 
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Enabling Tracing for an 
Instance 


SQL Trace Files and 
File Versions 


Running TKPROF 


To enable the SQL trace facility for all ORACLE users, set the value of 
the INIT.ORA parameter SQL_TRACE to TRUE. This value causes 
statistics to be collected for all users' sessions. You may, however, 
disable tracing for an individual session by executing this SQL 
statement in that session: 

ALTER SESSION SET SQL_TRACE FALSE 

When the SQL trace facility is enabled for an instance, ORACLE creates 
trace files every time a user connects and disconnects. Before running 
TKPROF, you may want to append all trace files into one file. 

Note: The first few trace files created after starting the database contain 
data that reflects the activity of the startup process. In particular, they 
contain statistics that reflect a disproportionate amount of I/O activity 
as the various caches in the database are filled. These first few files can 
usually be ignored. 


When you enable the SQL trace facility for an instance, ORACLE writes 
a trace file each time a user connects and disconnects. Refer to your 
Installation and User's Guide for information on how trace files are 
named and handled by your operating system. If your operating 
system retains multiple versions of files, make sure your version limit is 
high enough for the number of trace files you expect the SQL trace 
facility to generate. It is likely that ORACLE will create multiple trace 
files, and you should know how to distinguish them in the user dump 
directory. 

TKPROF translates the trace file produced by the SQL trace facility into 
readable format. TKPROF can also be used to generate EXPLAIN 
PLAN output. Invoke TKPROF as follows: 

TKPROF tracefile outputfile 

[SORT= {sortoption | (sortoption[,sortoption...])}] [PRINT=n] 
[EXPLAIN=username/password] 

Online help information is displayed if you invoke TKPROF without 
any command line arguments. 

The following are the arguments you use to run TKPROF. Refer to the 
section 'TKPROF Example" for how to specify these arguments. 

tracefile This argument is the name of the trace file where 

the SQL trace statistics were written after tracing 
was enabled. 
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outputfile 

This argument is the name of the file to which 

TKPROF will write its output. 

SORT 

This optional argument causes the statistics in the 
output file to be displayed in sorted order. If more 
than one sort option is specified, the output is 
sorted in descending order by the sum of the 
values specified in the sort options. For example, if 
EXECPU and EXEELA are specified, then SQL 
statements are sorted by the sum of cpu plus 
elapsed time spent executing. The sort options are: 

PRSCNT 

Number of times parsed 

PRSCPU 

CPU time spent parsing 

PRSELA 

Elapsed time spent parsing 

PRSPHR 

Number of physical reads during parse 

PRSCR 

Number of consistent mode block reads during 
parse 

PRSCU 

Number of current mode block reads during parse 

EXECNT 

Number of executes 

EXECPU 

CPU time spent executing 

EXEELA 

Elapsed time spent executing 

EXEPHR 

Number of physical reads during execute 

EXECR 

Number of consistent mode block reads during 
execute 

EXECU 

Number of current mode block reads during 
execute 

EXEROW 

Number of rows processed during execute. 

FCHCNT 

Number of fetches 

FCHCPU 

CPU time spent fetching 

FCHELA 

Elapsed time spent fetching 

FCHPHR 

Number of physical reads during fetch 

FCHCR 

Number of consistent mode block reads during 
fetch 

FCHCU 

Number of current mode block reads during fetch 

FCHROW 

Number of rows fetched 
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PRINT=n 


TKPROF Example 


This optional argument causes the first n (integer) 
sorted SQL statements that were analyzed in the 
trace session or instance to be printed in the output 
file. 

EXPLAIN This optional argument instructs TKPROF to run 

=username/pa$sword the EXPLAIN PLAN statement on all SQL 

statements in the trace file. The EXPLAIN PLAN 
statement produces execution plans of SQL 
statements. EXPLAIN PLAN logs in with the 
username/passiuord you provide in this argument, 
creates a PLAN_TABLE, and deletes the 
PLAN_TABLE when it finishes executing. For 
information on the EXPLAIN PLAN statement, see 
the "The EXPLAIN PLAN Statement" section in 
this chapter. 

The user process must have RESOURCE privileges 
to use the EXPLAIN argument in TKPROF. 

The following example shows how you can run TKPROF on the VMS 
operating system: 

TKPROF SQLDBA_JRL_005.TRC Rl.PRF SORT=(EXECPU,FCHCPU) EXPLAIN=SCOTT/TIGER 

In this example, the tracefile written by the SQL trace facilty is named 
SQLDBAJRL_005.TRC. TKPROF generates statistics for each 
statement traced. The statistics are sorted in the outputfile, Rl.PRF, by 
the sum of CPU time spent executing and the CPU time spent fetching 
rows. All statements of the trace file and an execution plan for each 
statement are printed in R1 .PRF. 
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TKPROF Output 


SQL Trace Facility 
Statistics 


The following shows TKPROF output for one SQL statement that 
appears in the output file. TKPROF was run with EXPLAIN as a 
command line option: 

SELECT * FROM EMP, DEPT WHERE EMP.DEPTNO = DEPT.DEPTNO 

count cpu elap phys cr cur rows 


Parse: 
Execute: 
Fetch: 


1 88 

1 5 

1 10 


98 

12 

18 


OF 'DEPT' 

OF 'EMP' 


3 37 

2 2 

2 2 


0 

2 0 

2 14 


Execution plan: 

MERGE JOIN 

SORT JOIN 

TABLE ACCESS (FULL) 
SORT JOIN 

TABLE ACCESS (FULL) 


The SELECT statement that was traced is shown, followed by SQL trace 
statistics, and then the execution plan generated by EXPLAIN. For 
more information on execution plans, see "Example of EXPLAIN PLAN 
Output" in this chapter. 


The rows of the SQL trace facility output correspond to the parse, 

execute, and fetch steps of SQL statement processing: 

Parse The parse step translates the SQL statement into an 

execution plan. This step includes checks for 
proper security authorization and checks for the 
existence of tables, column names, and other 
referenced objects. 

Execute The execute step traces the running of the 

statement against the RDBMS. 

Fetch The fetch step retrieves the rows that satisfy a 

query. 

The following are the columns of the SQL trace facility output: 

count The number of times a SQL statement is parsed or 

executed and the number of fetch calls issued for 
the statement in order to perform the operation. 
Multiple data blocks may be read by each fetch 
call. 

cpu Total CPU time for the parse, fetch, or execute step 

in hundredths of seconds. 
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Recursive Calls 


elap Total elapsed time for each step in hundredths of 

seconds. 

phys Total number of data blocks read from the 

database files on disk for the processing step. 

cr The number of buffers retrieved in consistent 

mode. A buffer is retrieved in consistent mode 
when a read consistent version of the buffer is 
needed. 

cur The number of buffers retrieved in current mode. 

A buffer is retrieved in current mode when the 
most recent version of the buffer is needed. 

The sum of consistent reads and current reads 
equals the total number of data blocks that were 
accessed. 

rows The total number of rows processed by the SQL 

statement (not including rows processed by 
subqueries of the SQL statement). 

For SELECT statements, the number of rows 
returned appears in the row for the fetch step. 

For UPDATE, DELETE, and INSERT statements, 
the number of rows processed appears in the row 
for the execute step. 

Note: The timing statistics have a resolution of one hundredth of a 
second. This means that any operation on a cursor that takes a 
hundredth of a second or less may not be timed accurately. You should 
keep this in mind when interpreting these statistics. In particular, be 
careful when interpreting the results from simple queries that execute 
very quickly. 

In order to execute a SQL statement, ORACLE may have to execute an 
additional SQL statement or statements. Such statements are referred 
to as recursive calls. For example, if you try to insert a row into a table 
which does not have enough space, ORACLE makes recursive calls to 
allocate the space dynamically. Recursive calls are also generated when 
data dictionary information is not available in the data dictionary cache 
and must be retrieved from disk. 

If recursive calls occur while the SQL trace facility is enabled, TKPROF 
displays statistics on these statements in addition to the statements that 
initiated them. The recursive statistics are clearly marked as recursive 
SQL statements. Note, however, that CPU time, elapsed time. 


7-8 


ORACLE RDBMS Performance Tuning Guide 







physical, consistent, and current reads for recursive SQL statements 
are included in the statistics of the SQL statement that caused the 
recursive execution. When adding these statistics for several SQL 
statements, be careful not to double count trace statistics and statistics 
from recursive calls. 


The EXPLAIN PLAN Statement 

The EXPLAIN PLAN statement displays the execution plan chosen by 
the ORACLE optimizer for SELECT, UPDATE, INSERT, and DELETE 
statements (DDL statements are not included). An execution plan is a 
series of primitive operations, and an ordering of these operations, that 
the RDBMS performs to execute the statement. By examining the 
execution plan, you can see exactly how the RDBMS executes your SQL 
statement. This information can help you determine whether the SQL 
statement you have written takes advantage of the indexes available. 

For online documentation of the EXPLAIN PLAN statement, refer to 
the file EXPLAIN.DOC on the distribution media. 

Creating the EXPLAIN Before running the EXPLAIN PLAN statement, you must create a 
PLAN Output Table database table to contain the output for EXPLAIN PLAN. To create this 

table, a SQL script called XPLAINPL.SQL is provided on your 
distribution media in the same directory as CATALOG.SQL. For more 
operating system specific information on the location of 
CATALOG.SQL, refer to your Installation and Users Guide. To execute 
XPLAINPL.SQL, enter this expression in either SQL*Plus or SQL*DBA: 

SQL> 0XPLAINPL.SQL 

Alternatively, you may also create your own table using any name you 
choose. You can direct the output of the EXPLAIN PLAN statement to 
this table using the INTO clause described later in this section. 
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EXPLAIN PLAN 
Statement Syntax 


Any table used to store the output of the EXPLAIN PLAN statement 
must have the same column names and datatypes as this 
PLAN.TABLE: 

CREATE TABLE PLAN TABLE ( 


STATEMENT_ID 

CHAR(30) 

TIMESTAMP 

DATE, 

REMARKS 

CHAR(80) 

OPERATION 

CHAR 130) 

OPTIONS 

CHAR(30) 

OBJECT_NODE 

CHAR(30) 

OBJECT_OWNER 

CHAR(30) 

OBJECT_NAME 

CHAR(30) 

OBJECT_INSTANCE 

NUMERIC, 

OBJECT_TYPE 

CHAR(30) 

SEARCH_COLUMNS 

NUMERIC, 

ID 

NUMERIC, 

PARENT_ID 

NUMERIC, 

POSITION 

NUMERIC, 

OTHER 

LONG); 


The syntax of the EXPLAIN PLAN statement is: 

EXPLAIN PLAN (SET STATEMENT_ID = 'description'] 

[INTO table_name] 

FOR sql_statement 

where: 

description An optional identifier (a quoted string of up to 30 

characters) for the statement. If you do not set the 
STATEMENT_ID, the description will be NULL. It 
is advisable to create an identifier for this field to 
identify your EXPLAINed statements, since the 
PLANET ABLE may be shared or appended to by 
other users. 

tabie name An optional clause specifying the name of the 

output table into which you wish to save the 
results of the EXPLAIN PLAN statement. The 
table must conform in column name, type, and 
length to the PLAN_TABLE described in the 
section "Creating the EXPLAIN PLAN Output 
Table". If omitted, EXPLAIN PLAN will attempt to 
insert into a table named PLAN_TABLE owned by 
the current user. 
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sql_statement 

The entire text of the INSERT, DELETE, UPDATE, 
or SELECT statement against which you want to 
run EXPLAIN PLAN. 


EXPLAIN PLAN T able The PLAN_TABLE used by the EXPLAIN PLAN statement contains the 
Columns following columns: 

STATEMENTJD The optional identifier you specified in the 


TIMESTAMP 

EXPLAIN PLAN statement. 

The date and time when the statement was 
analyzed. 

REMARKS 

Any comment (of up to 80 characters) you wish to 
associate with each step of the explained plan. If 
you need to add or change a remark on any row of 
the PLAN JTABLE, use the UPDATE statement to 
modify the rows of the PLAN_TABLE. 

OPERATION 

The name of the internal operation performed in 
this step. See Table 7-1. 

OPTIONS 

Further describes the OPERATION carried out in a 
step. See Table 7-2. 

OBJECT_NODE 

The name of the database link used to reference the 
object (a table name or view name). 

OBJECTOWNER 

The name of the user that owns the table or index. 

OBJECT_NAME 

The name of the database table or index. 

OBJECT, 

INSTANCE 

A number corresponding to the ordinal position of 
the object as it appears in the original statement. 

The numbering proceeds from left to right, outer to 
inner with respect to the original statement text. 

Note that view expansion will result in 
unpredictable numbers. 

OBJECT_TYPE 

A modifier that provides descriptive information 
about the database object, for example, 

NON-UNIQUE for indexes. 

SEARCH _ 
COLUMNS 

Not used in current release. 

ID 

A number assigned to each step in the execution 
plan. 
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TABLE 7-1 
Operation Names 
Used by EXPLAIN PLAN 


PARENT_ID The ID of the next execution step that operates on 

the output of the ID step. For a description of how 
ID and PARENTJD show the order of processing 
of the execution plan, see "Example of EXPLAIN 
PLAN Output" and Figure 7-1 in this chapter. 

POSITION The order of processing for steps that all have the 

same PARENTJD. 

OTHER Other information that is specific to the execution 

step that a user may find useful. For example, for 
distributed queries, OTHER might contain the text 
of the SQL statement sent to a remote node. 

Table 7-1 lists the internal operations performed by the RDBMS when 

processing a SQL statement: 

Operation Description 


AND-EQUAL 


CONNECT BY 


CONCATENATION 

COUNTING 

FILTER 
FIRST ROW 
FOR UPDATE 
INDEX 

INTERSECTION 
MERGE JOIN 


A retrieval utilizing intersections of ROWIDS from 
index searches. This operation is used for WHERE 
clauses containing equality comparisons ANDed 
together, where each comparison includes a 
non-unique indexed column. It obtains the ROWIDs 
from each of these comparisons and performs 
the intersection. 

A retrieval based on a tree-walk. It is used 
to execute the CONNECT BY clause in SELECT 
statements. 

A retrieval from a group of tables. It is a UNION 
ALL operation of the sources. 

An operation that counts the number of rows returned 
from a table. 

A restriction of the rows returned from a table. 

A retrieval of only the first row of a query result. 

A retrieval that places row locks on selected rows. 

A retrieval from an index. This operation has further 
options. See Table 7-2. 

A retrieval of rows common to two tables. The 
rows are first sorted. 

A join performed by merging two sorted sets of 
operands. This operation has further options. 

See Table 7-2. 
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MINUS 


NESTED LOOPS 


PROJECTION 

REMOTE 

SEQUENCE 

SORT 

TABLE ACCESS 

UNION 

VIEW 


A retrieval of rows in source table 1 but not 
source table 2. 

A join operation performed on two child 
operations. For each row returned by the first 
child operation, the second child operation is 
performed. This operation has further options. 

See Table 7-2. 

A retrieval of a subset of columns from a table. 

A retrieval from a database other than the current 
database. 

An operation involving a sequence generator. 

A retrieval of rows ordered on one or more columns. 
This operation has further options. See Table 7-2. 

A retrieval from a base table. This operation has 
further options. See Table 7-2. 

A retrieval of unique rows from two tables. 

The duplicates are dropped. 

A retrieval from a virtual table. 


Table 7-2 shows OPERATIONS that have OPTIONS further describing 
the processing step: 

TABLE 7-2 Operation Options Description 

Operations That Have Options —— 


INDEX 

UNIQUE SCAN 

Index lookup for unique value. 


RANGE SCAN 

Index lookup for range of values 
retrieved with the BETWEEN 
logical operator. 

MERGE JOIN 

OUTER 

An outer join. 

NESTED LOOPS 

OUTER 

An outer join. 

SORT 

UNIQUE 

A sort to produce unique values. 


GROUP BY 

A sort for grouping operation. 


JOIN 

A sort for merge join. 


ORDER BY 

A sort for order by. 

TABLE ACCESS 

BY ROWID 

Table access by ROWID. 

The ROWID is retrieved from 
the index, then the row is looked 
up in the table. 


FULL 

Table access by full table scan. 


CLUSTER 

Table access by cluster key. 
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Example of EXPLAIN 
PLAN Output 


Table Format of EXPLAIN 
PLAN Output 


The following example shows a SQL statement and its corresponding 
execution plan generated by using the EXPLAIN PLAN statement. 

This query retrieves names and related information for employees 
whose salary is not within any range of the SALGRADE table. 

SELECT ENAME, JOB, SAL, DNAME 
FROM EMP, DEPT 

WHERE EMP.DEPTNO = DEPT.DEPTNO 
AND NOT EXISTS 

{SELECT * 

FROM SALGRADE 

WHERE EMP.SAL BETWEEN LOSAL AND HISAL) 

This EXPLAIN PLAN statement generates an execution plan and places 
the output in PLAN_TABLE: 

EXPLAIN PLAN 

SET STATEMENT_ID = 'EMP_SAL' 

FOR 

SELECT ENAME, JOB, SAL, DNAME 
FROM EMP, DEPT 

WHERE EMP.DEPTNO = DEPT.DEPTNO 
AND NOT EXISTS 

(SELECT * 

FROM SALGRADE 

WHERE EMP.SAL BETWEEN LOSAL AND HISAL) 


This SELECT statement generates the following output: 

SELECT OPERATION, OPTIONS, OBJECT_NAME, ID, PARENT_ID, POSITION 
FROM PLAN_TABLE 
WHERE STATEMENT_ID = 'EMP_SAL' 

ORDER BY ID 


OPERATION 

OPTIONS OBJECT_NAME 

ID PARENT_ 

ID POSITION 

FILTER 


1 


0 

MERGE JOIN 


2 

1 

1 

SORT 

JOIN 

3 

2 

1 

TABLE ACCESS 

FULL DEPT 

A 

3 

1 

SORT 

JOIN 

5 

2 

2 

TABLE ACCESS 

FULL EMP 

6 

5 

1 

TABLE ACCESS 

FULL SALGRADE 

7 

1 

2 
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Nested Format of 
EXPLAIN PLAN Output 


When ORDER BY ID is specified, the ID column lists operations 
sequentially. However, the statement was not executed in the order of 
the ID column. Since PARENT_ID receives information from ID, 
observe that more than one ID step fed PARENT ID. For example, step 
2, a merge join, and step 7, a table access, both fed step 1. A nested, 
visual representation of the processing sequence is shown in the section 
'Nested Format of EXPLAIN PLAN Output.” 

This type of SELECT statement generates a nested representation of the 
output that more closely depicts the order of steps undergone in 
processing the SQL statement. The order resembles a "tree-structure," 
which is illustrated in Figure 7-1. 

SELECT LPAD(' ',2*LEVEL) ||OPERATION||' 'I I OPTIONS| P ' | |OBJECT_NAME QUERY_PLAN 
FROM PLAN_TABLE WHERE STATEMENT_ID = 'EMP_SAL' 

CONNECT BY PRIOR ID = PARENT_ID AND STATEMENT_ID='EMP_SAL' 
START WITH ID = 1 

QUERY PLAN 

FILTER 

MERGE JOIN 
SORT JOIN 

TABLE ACCESS FULL DEPT 
SORT JOIN 

TABLE ACCESS FULL EMP 
TABLE ACCESS FULL SALGRADE 
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FIGURE 7-1 
Tree-structure of 
Execution Plan 



This tree-structure diagram illustrates how operations that occur 
during the execution of a SQL statement feed into one another. Each 
step in the execution plan is assigned a number (representing the ID 
column of the PLAN_TABLE) and is depicted by a "node." The result 
of each node's operation is passed to the parent node higher in the tree. 
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APPENDIX 

A 



Initial RDBMS 

Installation 

Guidelines 

M ost of this Guide assumes that you are tuning an ORACLE 
RDBMS that is already running. However, many significant 
tuning alterations to the RDBMS may be made during installation. This 
appendix gives tuning recommendations for installation of the 
ORACLE RDBMS. By following these instructions during installation, 
you can reduce the need to tune the RDBMS when it is running. This 
appendix gives recommendations for these installation issues: 

• changing the values of INIT.ORA parameters from their 
defaults 

• allocating rollback segments 
• distributing I/O 
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Changing the Values of INIT.ORA Parameters 


DB_BLOCK_BUFFERS 


Data Dictionary Cache 
Parameters 


This section lists INIT.ORA parameters whose values should be 
changed from their defaults when you install the ORACLE RDBMS 
Version 6.0. 

This parameter determines the number of buffers in the buffer cache in 
the System Global Area (SGA). The number of buffers affects the 
performance of the cache. Larger cache sizes reduce the number of 
writes of modified data. However, a large cache may take up too much 
memory and induce paging or swapping, depending on your operating 
system. 

Estimate the number of database blocks that your application accesses 
most frequently, including tables, indexes, and rollback segments. This 
estimate is a rough approximation of the minimum number of buffers 
the cache should have. 

For more information on the buffer cache, refer to Appendix B "The 
Database Writer Process (DBWR)." 

The 21 data dictionary cache parameters determine the sizes of the data 
dictionary caches in the SGA. These parameters all begin with "DC_". 
Each parameter determines the number of entries in one of the data 
dictionary caches. You will probably find it useful to increase the 
values of these parameters from their defaults: 

DC_COLUMNS Set this parameter to the number of distinct 

columns referenced by all concurrent users. For 
many applications, the default value of 300 is too 
low. 

DC_TABLES Set this parameter to the number of distinct tables 
referenced by all concurrent users. For many 
applications, the default value of 100 is too low. 

For more information on the data dictionary cache, refer to Chapter 3 
'Tuning Memory Allocation." 


A - 2 


ORACLE RDBMS Performance Tuning Guide 








FREEJLIST.PROC 


LOG,ALLOCATION 


PROCESSES 


ROLLBACK, 

SEGMENTS 


SEQUENCE_CACHE_ 

ENTRIES 


SORT, ARE A_SIZE 


This parameter determines the number of free lists for each table. 
ORACLE uses free lists to hold blocks that are available to accept new 
rows. If many processes concurrently insert new rows into the same 
table, you should increase the value of this parameter. If your 
ORACLE database is accessed by a single ORACLE instance, the 
maximum value for this parameter is 32. For more information on free 
lists, refer to Chapter 6 "Additional Tuning Considerations." 

This parameter determines the number of blocks in the redo log file 
allocated to an ORACLE instance when the instance requires more 
space in the file. If your ORACLE database is accessed by a single 
instance, set this parameter to a value larger than the size of your 
largest log file to prevent unnecessary allocations. 

This parameter determines the maximum number of operating system 
processes that can be connected to ORACLE concurrently. The value of 
this parameter must include 5 for the background processes and 1 for 
each user process. For example, if you plan to have 50 concurrent 
users, set this parameter to at least 55. 

This parameter is a list of the rollback segments an ORACLE instance 
acquires at database startup. List your rollback segments as the value 
of this parameter. To determine how many rollback segments you 
need, refer to the section "Allocation Rollback Segments" later in this 
appendix. 

After installation, you must create at least one rollback segment in the 
SYSTEM tablespace in addition to the SYSTEM rollback segment before 
you can create any other database objects. 

This parameter determines how many sequences can be cached in the 
SGA for quick access. The default value for this parameter is 10. This 
value is adequate for most applications. If your applications use more 
than 10 sequences concurrently, increase the value of this parameter. 

This parameter determines how much memory ORACLE allocates for a 
sort operation. The default value is usually large enough for most 
sorts. However, if you create very large indexes or perform SQL 
statements with GROUP BY or ORDER BY clauses that access very 
large tables, you should increase the value of this parameter. For more 
information on tuning sorts, refer to Chapter 6 "Additional Tuning 
Considerations." 
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Allocating Rollback Segments 


Proper allocation of rollback segments makes for optimal database 
performance* The sice atuJ ciumOei uf rvffOacA oc^iilCitp injumu iui 
optimal performance depends on your application. For information on 
the purpose of rollback segments, refer to Chapter 5 "Tuning 
Contention." 


The following are some general guidelines for choosing how many 
rollback segments to allocate based on the number of concurrent 
transactions on your RDBMS. These guidelines are appropriate for 
most application mixes: 


Number of Concurrent Recommended Number 

Transactions of Rollback Segments 


fewer than 16 
16 to 32 
32 or more 


4 segments 
8 segments 

n/4 but not more than 50 


To create rollback segments, use the CREATE ROLLBACK SEGMENT 
statement. For more information on this statement, refer to the 
SQL Language Reference Manual . 


Choosing Sizes for The size of your rollback segment can also affect performance. Rollback 
Rollback Segments segment size is determined by the storage parameters in the CREATE 

ROLLBACK SEGMENT statement. Your rollback segments must be 
large enough to hold the rollback entries for your transactions. 

For Long Queries and Some applications perform long queries on data that is being modified 
Long Transactions concurrently by other transactions. Such queries may require access to 

rollback segments to reconstruct a read-consistent version of the 
modified data. These rollback segments must be large enough to hold 
all the rollback entries for the data while the query is running. 

Large rollback segments can also improve the performance of single 
transactions that modify large amounts of data. Such transactions 
generate large rollback entries. If a rollback entry does not fit into a 
rollback segment, ORACLE extents the segment. Dynamic extension 
reduces performance and should be avoided whenever possible. 
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For OLTP Applications 

Be sure all of your rollback segments are the same size. Creating a 
single large rollback segment does not guarantee that large rollback 
entries will not cause extension. Since transactions are assigned to 
rollback segments randomly, you cannot be sure that a particularly 
large transaction will be assigned to a large rollback segment rather 
than to a smaller one. 

Some applications perform online transaction processing , or OLTP. OLTP 
applications are characterized by frequent concurrent transactions that 
modify small amounts of data. If your application performs only OLTP 
with no long queries or long transactions, you can improve 
performance by creating many small rollback segments. It may help to 
have as many rollback segments as concurrent transactions. Each 
transaction can then access a separate rollback segment with no risk of 
contention. 

Small rollback segments are more likely to remain stored in the buffer 
cache where they can be accessed quickly. A typical OLTP rollback 
segment might have 2 extents, each on the order of 10 kilobytes in size. 

Distributing I/O 

Proper distribution of I/O can improve database performance 
dramatically. I/O can be distributed during installation of the 

ORACLE RDBMS. Distributing I/O during installation can reduce the 
need to distribute I/O later when the RDBMS is running. 

There are several ways to distribute I/O when you install the ORACLE 
RDBMS: 

• redo log file placement 

• database file placement 

• separation of tables and indexes 

• density of data (rows per block) 

For complete information on each of these issues, refer to Chapter 4 
'Tuning I/O." 
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APPENDIX 

B The Database 

Writer Process 

(DBWR) 

T he Database Writer process (DBWR) and the management of the 
buffer cache in the System Global Area (SGA) have been changed 
significantly in Version 6.0.27 of the ORACLE RDBMS. In previous 
releases of ORACLE Version 6.0, DBWR was a focal point of the tuning 
process. In ORACLE Version 6.0.27 and subsequent releases, the 
DBWR process should not require tuning attention. 

This appendix describes the operation of the DBWR process in 
ORACLE Version 6.0.27 and subsequent releases of ORACLE Version 
6.0. The following topics are discussed: 

• buffer cache structure 
• reading data into the buffer cache 
• writing data to database files 
• signalling DBWR to write 
• monitoring DBWR 
• tuning DBWR 
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Buffer Cache Structure 


The buffers in the buffer cache hold copies of database blocks that are 
accessed frequently by ORACLE processes. Each buffer in the cache 
can hold a single ORACLE block. The number of buffers in the cache 
is specified by the INIT.ORA parameter DB_BLOCK_BUFFERS. 


Buffer Cache Lists The buffers in the cache are organized lit two lists: 

• the dirty list 

• the least-recently-used (LRU) list 

The dirty list holds dirty buffers. A dirty buffer is a buffer that has been 
modified but has not yet been written to disk. 

The least-recently-used (LRU) list holds free buffers, pinned buffers, and 
dirty buffers that have not yet been moved to the dirty list. Free buffers 
are buffers that have not been modified and are available for use. 
Pinned buffers are buffers that are currently being modified. 

When an ORACLE process accesses a buffer, the process moves the 
buffer to the most-recently-used (MRU) end of the LRU list. As more 
buffers are continually moved to the MRU end of the LRU list, dirty 
buffers "age” towards the LRU end of the LRU list. 


Reading Data into the Buffer Cache 

When an ORACLE user process needs to access a block stored in the 
buffer cache, the process moves the buffer that holds the block to the 
MRU end of the LRU list. The process then accesses that buffer. 

When a user process needs to access a block that is not already in the 
buffer cache, the process must read the block from a database file on 
disk into a buffer in the cache. Before reading a block into the cache, 
the process must first find a free buffer. The process searches the LRU 
list, starting at the LRU end of the list. The process searches either until 
it finds a free buffer or until it has searched the number of buffers 
specified by the INIT.ORA parameter DB_BLOCK_MAX_SCAN_CNT. 
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As a user process searches the LRU list, it may find dirty buffers. If the 
user process finds a dirty buffer, it moves the buffer to the dirty list and 
continues to search. 

When a user process finds a free buffer, it reads the block into the 
buffer and moves it to the MRU end of the LRU list. 

If an ORACLE user process searches DB_BLOCK_MAX_SCAN_CNT 
buffers without finding a free buffer, the process stops searching the 
LRU list and signals the DBWR process to write some of the dirty 
buffers to disk. Refer to the section "Signalling DBWR to Write" later in 
this appendix. 


Writing Data to Database Files 

All the writing of buffers to database files is performed by the Database 
Writer process (DBWR), an ORACLE background process responsible 
for buffer cache management. The primary job of the DBWR process is 
to keep the buffer cache clean. As buffers in the cache are modified 
("dirtied") by user processes, the number of free buffers diminishes. If 
the number of free buffers drops too low, user processes that must read 
blocks from disk into the cache will not be able to find free buffers. 
DBWR manages the buffer cache so that user processes can always find 
free buffers. 

The LRU arrangement of the buffer cache is designed to minimize I/O. 
Blocks that are used often, e.g., blocks in frequently accessed, small 
tables or indexes, are kept in the cache so that they do not need to be 
read in again from disk. Blocks that are accessed infrequently, e.g., 
blocks from very large tables or leaf blocks from very large indexes, are 
written to disk after they have been modified to make room in the 
buffer cache for other blocks. The LRU scheme causes more frequently 
accessed blocks to stay in the buffer cache so that when a buffer is 
written to disk, it is unlikely to contain data that would have been 
useful soon. However, if the DBWR process becomes too active it may 
write blocks to disk that are about to be modified again. 
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Signalling DBWR to Write 

The DBWR process is signalled to write dirty buffers to disk under 
these conditions: 

• When a user process moves a buffer to the dirty list and 
discovers that the dirty list has reached a threshold length, the 
user process signals DBWR to write. The threshold length is 
defined to be one half of the value of the INIT.ORA parameter 
DB_BLOCK_WRITE_BATCH. 

• When a user process searches DB_BLOCK_MAX_SCAN_CNT 
buffers in the LRU list without finding a free buffer, the user 
process stops searching the LRU list and signals DBWR to 
write. 

• When a timeout occurs (every 3 seconds), DBWR signals itself. 

• When a checkpoint occurs, the Log Writer process (LGWR) 
signals DBWR. 

In the first two cases DBWR writes the blocks on the dirty list to disk 
with a single multi-block write. The number of blocks written in a 
multi-block write is specified by the INIT.ORA parameter 
DB_BLOCK_WRITE_BATCH. If the dirty list does not have 
DB_BLOCK_WRITE_BATCH buffers when DBWR is signalled, DBWR 
searches the LRU list for additional dirty buffers. 

A timeout occurs if DBWR is inactive for 3 seconds. In this case, DBWR 
searches a specified number of buffers on the LRU list and writes any 
dirty buffers that it finds to disk. Whenever a timeout occurs, DBWR 
searches a new set of buffers. The number of buffers searched by 
DBWR at each timeout is twice the value of the INIT.ORA parameter 
DB_BLOCK_WRITE_BATCH. If the database is idle, DBWR eventually 
writes the entire buffer cache to disk. 

When a checkpoint occurs, the Log Writer process (LGWR) specifies a 
list of modified buffers that must be written to disk. DBWR writes the 
specified buffers to disk. 
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ORACLE compiles statistics reflecting the activity of the DBWR process: 

dbwr free low The value of this statistic is the number of times 

DBWR was signalled to write because the number 
of buffers on the dirty list reached one-half 
DB_BLOCK_WRITE_BATCR 

dbwr free needed The value of this statistic is the number of times 

DBWR was signalled to write because a user 
process searched DB_BLOCK_MAX_SCAN_CNT 
buffers without finding a free buffer. 

These statistics are available through the SQL*DBA MONITOR 
STATISTICS CACHE display. To view the display, issue the SQL*DBA 
command: 

SQLDBA> MONITOR STATISTICS CACHE 

The SQL*DBA MONITOR STATISTICS CACHE display is made up of 
two screens. Figures B-l and B-2 show these screens. In Figure B-2, 
you can see that the second screen of the display contains the statistics 
dbwr free low and dbwr free needed. 

ORACLE'S buffer cache management is designed so that user processes 
should not scan DB_BLOCK_MAX_SCAN_CNT buffers without 
finding a free buffer. For this reason, values of dbwr free needed should 
always be 0. In Figure B-2, you can see that the total value for the dbwr 
free needed statistic is 0. 

If you observe a dbwr free needed value greater than 0, be sure the value 
of DB_BLOCK_MAX_SCAN_CNT has not been set too low. The value 
of this parameter should not be changed from its default of 30 buffers. 
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FIGURE B-l 
SQL*DBA MONITOR 
STATISTICS CACHE Display 
(Screen 1) 


FIGURE B-2 
SQL*DBA MONITOR 
STATISTICS CACHE Display 
(Screen 2) 
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0.00 

0 

consistent changes 

2.77 

2.77 

2. 

77 

2.77 

36 

urite conplete uaits 

0.Z3 

0.Z3 

0. 

23 

0.23 

3 

urite wait tine 

0.00 

0.00 

0. 

00 

0.00 

0 

buffer busy uaits 

0.00 

0.00 

0. 

00 

0.00 

0 

busy ualt tine 

0. 00 

0.00 

0. 

00 

0.00 

0 

redo synch urites 

0.69 

0.69 

0. 

.69 

0.69 

9 

redo synch tine 

0.00 

0.00 

0. 

.00 

0.00 

0 

DBUR exchange uaits 

0.00 

0.00 

0. 

.00 

0.00 

0 

exchange deadlocks 

0.00 

0.00 

0. 

.00 

0. 00 

0 

free buffer requeste 

45.31 

45.31 

45. 

.31 

45.31 

589 

free buffer scans 

45.31 

45.31 

45. 

.31 

45.31 

589 

free buffer inspecte 

859.85 

859.85 

859, 

.85 

859.85 

11178 

free buffer uaits 

2.38 

2.38 

2. 

.38 

2.38 

31 

free uait tine 

0.00 

0.00 

0, 

.00 

0.00 

0 


ORACLE PID: 0 
Statistic None 


...continued (page Z) 
dbur tineouts 
dbur free needed 
dbur free lou 
dbur buffers scanned 
dbur checkpoints 
consistent forceouts 


ORACLE 

Statistics Monitor 

Thu 

Jul 13 

Session 

si 0 

User None* 

SVSTEM STATISTICS 

CUR 

AUG 

MAX 

MIN 

TOT 

0.00 

0.00 

0.00 

0.00 

0 

0.00 

0.00 

0.00 

0.00 

0 

0.54 

0.54 

0.54 

0.54 

7 

10.77 

10.77 

10.77 

10.77 

140 

0.00 

0.00 

0.00 

0.00 

0 

0.00 

0.00 

0.00 

0.00 

0 
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Tuning DBWR 


Tn convo cas«s, you may want to experiment with increasing the value 
of the INIT.ORA parameter DB_BLOCK_WRITE_BATCH from its 
default. Increasing this parameter will: 

• reduce the frequency with which user processes signal DBWR 
to write 

• increase the number of blocks that DBWR attempts to write 

Increasing DB_BLOCK_WRITE_BATCH may increase the ability of 
DBWR: 

• to use operating system facilities to write blocks to different 
disks in parallel 

• to write adjacent blocks in a single I/O 


The Database Writer Process (DBWR) 
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APPENDIX 


c 


Changing 

INIT.ORA 

Parameters 


C ertain INIT.ORA parameters affect your system's performance. 

Where applicable, the performance related parameters described 
in this appendix show: 

• the parameter's name 
• its function and description 
• the default value and range of permissible values 
• when you might want to change the parameter 
• the effects of changing the parameter 
• references to other INIT.ORA parameters or publications 

To change INIT.ORA parameters, you must shut down and restart the 
RDBMS. Some INIT.ORA parameters that enable gathering 
performance data also increase overhead, such as TIMED_STATISTICS, 
SQL_TRACE, DB_BLOCK_LRU_STATISTICS, DB_BLOCK_LRU_ 
EXTENDED_STATISTICS, and event specification. Make sure you turn 
these parameters off when they are not needed. 
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You can display the current parameter settings of your system with the 
SQL*DBA command: 

SQLDBA> SHOW PARAMETERS 

See Chapter 14, "Database Startup and Shutdown," of the ORACLE 
RDBMS Database Administrator's Guide , for a discussion on access 
privilege to SQL*DBA. 


CONTEXT_AREA 

Description The amount of space in bytes the system initially allocates for a context 
area. The context area is used to store data structures necessary for 
execution of a SQL statement. 


D ef aul t 4096 bytes 

Range of Values The maximum size can be 1024 to 131072 bytes, depending on your 
operating system. User-written precompiled programs and the 
ORACLE Call Interface (OCI) can specify a different size when opening 
cursors. 


When to Change If your application processes: 

• long and complex SQL statements 

• tables with large numbers of columns 

• tables with long rows 

this parameter can help you by increasing the initial size of the context 
areas. There is one context area per parsed statement. To increase the 
number of bytes the context area will grow by when more space is 
needed, use the CONTEXT_INCR parameter. 


Effects of Change Increasing this parameter causes more memory to be used by each 

ORACLE user, reduces CPU usage slightly, and may reduce dynamic 
extension of the context area if users parse large SQL statements. 


Reference Chapter 3, "Tuning Memory Allocation"; your Installation and User's 
Guide ; "Context Areas" in Chapter 8 of the ORACLE RDBMS Database 
Administrator's Guide. 
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CONTEXTJNCR 

Description 

Default 
Range of Values 
When to Change 

Effects of Change 
Reference 


The number of bytes by which a context area will grow to 
accommodate large SQL statements in memory each time more space 
beyond the initial extent is needed. If a cursor cannot allocate 
additional memory, an error occurs. 

d\C for most systems 

1024 to 32768 bytes 

If CONTEXT_INCR is too small, many increments are needed to obtain 
enough memory in the context area for execution of SQL statements. If 
CONTEXT_INCR is too large, excess memory will be allocated and 
wasted. User-written precompiled programs and the ORACLE Call 
Interface (OCI) can specify a different initial size when opening cursors. 

When this parameter is increased, more memory for the context area 
will be allocated in fewer steps, slightly reducing CPU usage. 

Chapter 3, "Tuning Memory Allocation"; your Installation and Users 
Guide; "Context Areas" in Chapter 8 of the ORACLE RDBMS Database 
Administrator's Guide . 
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CPU_COUNT 

Description The number of CPUs available to the ORACLE instance. ORACLE sets 
the value of this parameter automatically. For single-CPU computers, 
the value is set to 0. 

The value of CPU_COUNT determines the default value of the 
INIT.ORA parameter LOG_5lMUL i ANisUU5_CUPijfcft. 

Default Operating system dependent 


When to Change ORACLE sets this parameter automatically. Do not change the value of 
this parameter. 

Effects of Change If the number of copy latches is 0, redo entries are copied on the redo 

allocation latch. If CPU_COUNT is 0, LOG_SIMULTANEOUS_COPIES 
will also be 0, forcing user processes to always copy on the redo 
allocation latch. If you wish to copy all redo entries on the redo 
allocation latch, you should set LOG_SIMULTANEOUS_COPIES, not 
this parameter. 


Reference The section "Redo Copy Latches" in Chapter 5; "Changing the Value of 
INIT.ORA Parameters" in Appendix A; LOG_SIMULTANEOUS_ 
COPIES. 
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Data Dictionary Cache Parameters 

Description The INIT.ORA "DC_" parameters control the sizes of the data 

dictionary caches. By checking the entries in the V$ROWCACHE table, 
you can determine whether each parameter is set adequately. The 
caches are listed below by name. The function, default, and range of 
values are given for each. 

Reference Chapter 3, ’’Tuning Memory Allocation”; "Changing the Value of 
INIT.ORA Parameters” in Appendix A. 

Data Dictionary Caches DC_COLUMN_GRANTS The number of entries in the column grant 

cache. Allow one for each column in use 
having grants, not one for each grant. The 
default value is 50. The range of values is 1 to 
unlimited. 

DC_COLUMNS The number of entries in the column 

description cache. The value should equal at 
least the highest number of columns in any 
single table. For best performance, the value 
should be close to the number of columns of 
all tables referenced by all concurrent users at 
any one time. The default value is 300 and 
the range is 150 to unlimited. You will 
probably find it useful to raise this parameter 
to the number of distinct columns referenced 
by all concurrent users at any one time. 

You may want to change the value of this 
parameter from its default on installation of 
ORACLE Version 6. A description of this 
appears in Appendix A. 

DC CONSTRAINT DEFS The number of entries in the constraint 

definition cache. The default is 200 and the 
range of values is unlimited. 

DC_CONSTRAlNTS The number of constraint identification 

numbers in the constraint cache. The default 
value is 150 and the range is unlimited. 

DC_FILES The number of entries in the file description 

cache. Allow one for each file associated with 
tablespaces in use. The default value is 25 
and the range of values is 1 to unlimited. 
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DCFREEEXTENTS 

DC_INDEXES 

DC_OBJ ECT_I DS 

DC_OBJECTS 

DC_ROLLBACK_ 

SEGMENTS 

DC_SEGMENTS 

DC SEQUENCE_ 
GRANTS 

DC_SEQUENCES 

DC_SYNONYMS 

DC_TABLE_GRANTS 


The number of entries in the free extent 
descriptions cache (which caches definitions 
of individual extents of free space, no matter 
what the size). The default is 50 and the 
range of values is 5 to unlimited. 

The number of entries in the index 
description cache. The default is 50 and the 
range of values is 20 to unlimited. 

The number of entries in the object identifier 
cache. The default is 50 and the range is 1 to 
unlimited. 

The number of entries in the object 
descriptions cache (which caches names of 
database objects such as tables, clusters, 
indexes, sequences, synonyms, and views). 
For best performance, the value should be as 
large as the number of objects in use by all 
users at any one time. The default is 100 and 
the range of values is 50 to unlimited. 

The number of entries in the rollback 
segment description cache. The default is 25 
and the range is 2 to unlimited. 

The number of entries in the segment 
description cache. Allow one for each table, 
cluster, index, and rollback segment in use at 
any one time. The default is 50 and the range 
is 50 to unlimited. 

The number of grants on sequences that can 
be cached. The default is 20 and the range is 
2 to unlimited. 

The number of entries in the sequence 
description cache. The default is 20 and the 
range is 2 to unlimited. 

The number of entries in the synonym 
description cache. The default is 50 and the 
range is 2 to unlimited. 

The number of entries in the table grant 
cache. One entry is needed for each table 
with grants, not for each grant. The default is 
50 and the range is 2 to unlimited. 
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DC TABLES 


DC_T A BLESP ACE 
QUOTAS 


DC_T A BLESP ACES 


DC_USED_EXTENTS 


DC_USERNAMES 


DCUSERS 


The number of entries in the 
table/cluster/view description cache. The 
default is 100 and the range of values is 30 to 
unlimited. You will probably find it useful to 
raise this parameter to the number of distinct 
tables referenced by all concurrent users at 
any one time. 

You may want to change the value of this 
parameter from its default on installation of 
ORACLE Version 6. A description of this 
appears in Appendix A. 

Number of entries in the tablespace quota 
cache, which caches individual users' quotas 
for each tablespace. The default is 25. You 
need one for each quota on each tablespace 
for each concurrent user. 

Note that unlimited RESOURCE privilege is 
NOT a quota. 

The number of entries in the tablespace 
description cache. The default value is 25 
and the range of permissible values is 25 to 
unlimited. You need one per online 
tablespace. 

The number of entries in the used extents 
description cache. The default is 50 and the 
range is 50 to unlimited. 

The size of the user name row cache. 
Usernames held here, such as SCOTT, are 
mapped to identification numbers. The 
default is 50 and the range is 1 to unlimited. 
This parameter should be set to the number 
of distinct usernames referenced or logged at 
any time. 

The size of the user row cache that contains 
user identification numbers, mapped from 
DCJJSERNAMES. The default is 50 and the 
number of entries is 1 to unlimited. 
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DB_BLOCK_BUFFERS 

Description Determines the number of buffers in the buffer cache of the SG A. Each 
buffer in the cache holds a single ORACLE data block. The higher the 
value, the less I/O is required, because of the increased likelihood that 
a required block is cached in memory. However, if the value is too 
high, the SGA may be paged, degrading performance. 

You may want to change the value of this parameter from its default on 
installation of ORACLE Version 6. A description of this appears in 
Appendix A. 

Default Operating system dependent 


Range of Values 4 to 65535 

When to Change When your hit ratio is less than 60% or 70%, increasing the number of 
buffers in the buffer cache may improve your application's 
performance. Applications which often reference common data will 
often show an improvement. 


Effects of Change By increasing the value for DBBLOCKJBUFFERS, you also increase: 

• the size of the SGA (System Global Area), which contains the 
buffer pool 

• the amount of data that can be cached 

• the probability that data will remain cached 

• memory usage 

• paging if physical memory is full 

The net effect is to improve performance, as long as paging is not 
excessive. The only tradeoff in increasing the size of the buffer pool is 
that memory usage and thus paging of both the SGA and the user 
processes may increase. Paging can be reduced or eliminated by 
proper tuning of your operating system. 

Reference The "Examining Buffer Cache Activity" section in Chapter 3; "Buffer 
Cache Structure" section in Appendix B; "Changing the Value of 
INIT.ORA Parameters" in Appendix A; your Installation and User's 
Guide. 
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DB_BLOCK_LRU_EXTENDED_STATISTICS 


Description 

Enables compilation of statistics in the X$KCBRBH table which 
measure the effects of increasing the number of buffers in the buffer 
cache in the SGA. When this facility is enabled, it keeps track of 
additional DB_BLOCK_LRU_EXTENDED_STATISTICS blocks and the 
number of disk accesses that would be saved if additional buffers were 
allocated. This tuning tool should be turned off during normal 
operation. 

Default 

0 

Range of Values 

0 to unlimited 

When to Change 

When compiling statistics for the X$KCBRBH table, set this parameter 
to the maximum size you want to use to evaluate the buffer cache. It 
should be set to 0 otherwise. 

Effects of Change 

Enables compilation of recent buffer statistics 

Reference 

The section "Enabling the X$KCBRBH Table" in Chapter 3. 


DB_BLOCK_LRU_STATISTICS 

Description Enables compilation of statistics in the X$KCBCBH table which 


Default 

measure the effect of fewer buffers in the buffer cache in the SGA. This 
tuning tool should be turned off during normal operation. 

FALSE 

Range of Values 

FALSE/TRUE 

When to Change 

Set this parameter to TRUE when you want to compile statistics for the 
X$KCBCBH table; otherwise leave it set to FALSE. 

Effects of Change 

Turns on current buffer statistics and inserts this data in the table 
XSKCBCBH. 

Reference 

The section "Enabling the X$KCBCBH Table" in Chapter 3. 
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DB_BLOCK_MAX_SCAN_CNT 

Description The number of buffers a user process will scan looking for a buffer on 
the LRU list, before invoking the Database Writer process (DBWR). 

Default 30 buffers 

Range of Values 0 to DB_BLOCK_BUFFERS 

When to Change Changing the value of this parameter is not recommended. 

Reference The "Buffer Cache Structure" section in Appendix B. 


DB BLOCK SIZE 


Description Defines the size in bytes of ORACLE database blocks. The 

DB_BLOCK_SIZE value in effect at CREATE DATABASE determines 
the size of the blocks; at all other times the value must be set to the 
original value. The block size can only be changed after database 
creation by recreating the database. 

This parameter also determines the size of the buffers in the buffer 
cache in the System Global Area (SG A). The number of bytes used for a 
new table (INITIAL extent) and how much more space is allocated for 
new data (NEXT extent) are rounded up to multiples of 
DB_BLOCK_SIZE. 

Default Usually 2048 or 4096 bytes, depending on your operating system 
Range of Values Operating system dependent 

When to Change This parameter is not used for tuning. Its value should not normally be 
changed. 

Reference The "Allocating Space in Data Blocks" section in Chapter 4. 
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DB_BLOCK_WRITE_BATCH 

Description For multi-block I/O, the number of blocks the Database Writer process 


Default 

(DBWR) passes at one time to the operating system for writing. 

8 blocks 

Range of Values 

1 to 128 blocks. If the operating system only supports one write to a 
device at a time, the value should be between 2 and 8, where the only 
purpose of batching is to save some latching, unlatching and other 
overhead. 

When to Change 

In most cases, you should not change this value. However, it may be 
advantageous to increase it in order to: 

• reduce the frequency with which user processes invoke DBWR 

• increase the number of blocks that DBWR attempts to write 
each time it is signalled 

Effects of Change 

Higher values increase the ability of DBWR to use operating system 
facilities to write blocks on different disks in parallel, to take advantage 
of disk head seeking optimization algorithms, and to write adjacent 
blocks in a single I/O. However, if your buffer cache is small, all blocks 
in a batch are pinned until they are all written, so a higher value 
increases the chance that a user process will have to wait to modify a 
block which is in a batch being written. You can increase this 
parameter until you notice the statistics write complete waits and write 
wait time increasing. 

Reference 

The "Tuning DBWR" section in Appendix B. 
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DB_FILE_MULTIBLOCK_READ_COUNT 

Description Used for multi-block reads, the maximum number of blocks read at one 



time when performing a sequential scan. The default value is a 
function of DB_BLOCK_BUFFERS and PROCESSES. 

Default 

Operating system dependent 

Range of Values 

Operating system dependent 

When to Change 

If your application performs many full table scans on large tables, 
increasing the value of this parameter from the default may improve 
performance. 

Effects of Change 

Increasing the value of this parameter increases the maximum number 
of blocks read by a single multi-block read. With a larger value, you 
may read the same amount of data with fewer multi-block reads. 

Reference 

The "Multi-Block Reads" section in Chapter 2. 

FREE JLIST_IN ST 


Description 

The number of instance free list sets. All processes attached to a 
particular instance will use one of the free lists associated with one 
instance free list set. Within the set, free lists are used by different 
processes. The value should equal the number of instances (1 for a 
single instance) and no performance gain is realized by exceeding this 
value. 

Default 

1 

Range of Values 

1 to the number of instances 

When to Change 

This parameter should be changed for multi-instance (or shared disk 
systems) according to the guidelines provided in Chapter 21 of the 
ORACLE RDBMS Database Administrator's Guide. 

Reference 

The "Free Lists" section in Chapter 6; FREE_LIST_PROC; Chapter 21 of 
the ORACLE RDBMS Database Administrator's Guide. 
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FREE_LIST_PROC 

Description 


Default 
Range of Values 
When to Change 

Effects of Change 
Reference 


The number of free lists per instance (FREE_LIST_INST) created for a 
table. The number used when the table is created is permanent for that 
table. 

You may want to change the value of this parameter from its default on 
installation of ORACLE Version 6. A description of this appears in 
Appendix A. 

1 free list 

1 to 32 for single-instance ORACLE 

If any table you will be creating will have very high INSERT activity, or 
if you are accumulating buffer busy waits at a steady rate while your 
application is running, check the V$WAITSTAT table. If you have 
buffer busy waits on the data block class, you should change this 
parameter. 

Increasing the value adds more free lists to tables that will be created. 

The section "Free Lists" in Chapter 6; "Changing the Value of 
INIT.ORA Parameters" in Appendix A; 'The Dynamic Performance 
VSWAITSTAT Table" in Chapter 5; FREE_LIST_INST. 
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LOG_ALLOCATION 

Description The number of redo log file blocks allocated to an ORACLE instance 
each time it requires more space in a current online log file. The 
number of allocations made for an instance is reflected in the statistic 
redo chunk allocations. 

You may want to change the value of this parameter from its default on 
installation of ORACLE Version 6. A description of this appears in 
Appendix A. 

Default 200 blocks 

Range of Values For single instance (or non-shared disk systems), set the allocation size 
equal to (or greater than) the size of the largest redo log file. 


When to Change 


This parameter should be changed for multi-instance (or shared disk 
systems) according to the guidelines provided in Chapter 21 of the 
ORACLE RDBMS Database Administrator's Guide. 


Effects of Change In single-instance systems, setting the parameter to a lower number of 
blocks than the redo log file will cause more redo chunk allocations than 
necessary from the redo log file, and reduce performance. 


Reference 'The Log Writer Process (LGWR)” section in Chapter 5; "Initial RDBMS 
Installation Guidelines" in Appendix A; Chapter 21 of the ORACLE 
RDMBS Database Administrator's Guide. 
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LOG.BUFFER 


Description 

The size in bytes of the redo log buffer. If the size is adequate, the 
statistic redo log space requests should be 0. 

Default 

Operating system dependent 

Range of Values 

At least four times the maximum block size, to unlimited. A value of 
65536 bytes or higher is not unreasonable. 

When to Change 

When the value of redo log space requests is not 0, which indicates that 
user processes are waiting for space in the buffer. 

Effects of Change 

If there is memory contention and you increase this value, you increase 
the number of log buffers for processes to write. 

Reference 

The '’Space in the Redo Log Buffer" section in Chapter 5. 


LOG_CHECKPOINT_INTERVAL 

Description The number of newly filled redo log file blocks needed to trigger a 



checkpoint. Regardless of this value, a checkpoint will always occur at 
a log switch. The size may exceed the actual size of any redo log file, in 
which case checkpoints occur only when switching logs. The number 
of checkpoints that have occurred for a given instance is shown in the 
statistic dbwr checkpoints. If LOG_CHECKPOINT_INTERVAL is set to a 
small value, checkpoints will occur frequently, and instance recovery 
will be fast. 

Default 

Operating system dependent 

Range of Values 

20 to unlimited 

When to Change 

To reduce the frequency of checkpoints to improve performance, set 
this parameter to a value equal to or larger than the size of your log 
files. 

Effects of Change 

Increasing this parameter increases recovery time but improves 
runtime performance. 

Reference 

"Additional Tuning Considerations," Chapter 6. 
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LOG_ENTRY_PREBUILDJTHRESHOLD 


Description 

Default 
Range of Values 
When to Change 

Effects of Change 

Reference 


The maximum size of a redo entry to prebuild before the copy to the 
log buffer. If enabled, it forces a user process to pre-build redo 
information before requesting the redo copy latch. If the value for 
LOG_SIMULTANEOUS_COPIES is 0, this parameter is ignored. 

0 

0,2048 or 4096 bytes, depending on your operating system. 

For multi-processor systems, it can be beneficial to increase this 
parameter. Single processor systems should keep the value at 0. 

For systems experiencing latch contention, increasing this value 
pre-builds log entries, decreasing the time that the copy latch is held. 

LOG_SIMULTANEOUS_COPIES; the "Reducing Contention for Redo 
Copy Latches" section in Chapter 5. 


LOG_SIMULTANEOUS_COPIES 

Description The maximum number of redo copy latches available to write log 
entries simultaneously. For good performance, you can have up to 
twice as many redo copy latches as CPUs. For single-processor 
systems, set to 0 so that all log entries are copied on the redo allocation 
latch. If this parameter is set to 0, LOG_SMALL_ENTRY_MAX_SIZE is 
ignored. 

Default If not specified, the number defaults to the number of CPUs 
(CPU_COUNT). 


Range of Values 
When to Change 

Effects of Change 


0 to unlimited. The value 0 turns off copy latches. 

This parameter should be changed when there is contention for redo 
copy latches, as shown by the SQL*DBA MONITOR LATCH display. 

If you increase the value, you will reduce contention for redo copy 
latches, because more users can be copying to the redo buffer at one 
time. 


Reference ’Tuning Contention," Chapter 5; LOG_SMALL_ENTRY_MAX_SIZE; 
CPU COUNT. 
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LOG_SMALL_ENTRY_MAX_SIZE 

Description The size in bytes of the largest copy to the log buffers that may occur 


Default 

under the redo allocation latch without obtaining a redo copy latch. If 
the value for LOG_SIMULTANEOUS_COPIES is 0, this parameter is 
ignored (all writes are "small" and made without the copy latch). If the 
redo entry is copied on the redo allocation latch, the user process 
releases the latch after the copy. If the entry is larger than this 
parameter, the user process releases the latch after allocating space in 
the buffer and getting a redo copy latch. 

800 bytes (on VMS) 

Range of Values 

Operating system dependent 

When to Change 

To reduce contention for the redo allocation latch, decrease this value. 

This reduces the number of redo entries copied on the redo allocation 
latch, as well as the size of these entries. 

Effects of Change 

When made smaller, the number of redo entries copied on the redo 
allocation latch, as well as the size of these entries, is reduced, but a 
redo copy latch must be acquired instead. 

Reference 

LOG_SIMULTANEOUS_COPIES; "The Redo Allocation Latch" section 
in Chapter 5. 
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MAX_DUMP_FILE_SIZE 

Description This parameter is used by the SQL trace facility and other system 

functions, such as abnormal internal errors that cause traces, to control 
the maximum size of the trace files they write. (Each function writes 
one trace file.) Specify a limit to avoid having trace files use all your 
disk space in case the trace file contains a dump of memory. If the limit 
is reached by a specific trace file, the trace file is truncated. 


This is a diagnostic tool that should only be changed for debugging, 
tracing, etc. 

Default 500 operating system blocks 
Range of Values 1 to unlimited 


When to Change 


Effects of Change 


You may want to change this value if: 

• You are running the SQL trace facility for a long session 

• You are concerned that trace files are taking up too much space 

Increasing this parameter allows more storage for your trace file, but 
reduces the amount of storage available for other purposes. 


Reference "Performance Diagnostic Tools," Chapter 7. 
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OPEN ^CURSORS 

Description Defines the total number of open cursors (context areas) a single 

process can have at once. This parameter does not control a system 
wide feature, rather the maximum address/memory space used by 
each process. The control of context areas is specific to your application. 

Default 50 cursors 


Range of Values 5 to 255 


When to Change If you want to reduce the amount of parsing done by your application, 
increase the number of cursors. You can see the amount of parsing that 
is done by running the SQL trace facility. 

Effects of Change If you reduce repeated SQL statement parsing, you may need more 
cursors/context areas to hold the parsed statements. Decreasing the 
number of cursors/context areas may increase the need for repeated 
parsing. 


Reference Programmer's Guide to the ORACLE Precompilers , and SQL*FORMS 

Designer's Reference; the "Context Areas and Cursors" section in 
Chapter 3. 


PROCESSES 

Description The maximum number of operating system user processes that can 
connect to ORACLE simultaneously. You may want to change the 
value of this parameter from its default on installation of ORACLE 
Version 6. A description of this appears in Appendix A. 


Default 25 processes 

Range of Values The minimum is 5 and the maximum is operating system dependent. 

The value of this parameter should include 5 for the background 
processes, plus one per concurrent logon. 


When to Change Increase this value when you add more concurrent users. 


Effects of Change If the value is too low, your system won't be able to support the 

required number of users; they will not all be able to log on to ORACLE. 


Reference "Initial RDBMS Installation Guidelines," Appendix A. 
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ROLLBACK_SEGMENTS 


Description 


This parameter is a list of the rollback segments acquired by the 
ORACLE instance at startup. You must name one or more rollback 
segments in this parameter. An instance will always acquire all the 
segments indicated by this parameter, even if the number of segments 
exceeds the minimum number of segments calculated to be required by 
the instance (using TRANSACTIONS/TRANSACTIONS_PER_ 
ROLLBACK_SEGMENT). The segments can be created with or 
without the keyword PUBLIC. Never specify the SYSTEM rollback 
segment as a value for this parameter. 

After installation, you must create at least one rollback segment in the 
SYSTEM tablespace in addition to the SYSTEM rollback segment before 
you can create any other database objects. 

You may want to consider the needs of your database application when 
you specify rollback segments in this parameter at installation. For 
installation recommendations, refer to Appendix A ’’Initial RDBMS 
Installation Guidelines." 


Default null 


Range of Values 

When to Change 
Effects of Change 
Reference 


The range of values for this parameter appropriate for the operation of 
your RDBMS depends upon your application. For guidelines on the 
appropriate number and size of rollback segments, refer to Chapter 5, 
’Tuning Contention." 

When there is contention for rollback segments, and you add more 
rollback segments, you must add their names to this parameter's value. 

Adding the name of a new rollback segment allows ORACLE to 
acquire the rollback segment on the next startup. 

"Initial RDBMS Installation Guidelines," Appendix A; the INIT.ORA 
parameters, TRANSACTIONS and TRANSACTIONS_PER_ 
ROLLBACK_SEGMENT in the ORACLE RDBMS Database 
Administrator's Guide. 
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ROWJLOCKING 


Description 

Use this parameter in conjunction with the INIT.ORA parameter 
SERIALIZABLE set to FALSE, to establish row-level locking as the 
default. 

For ORACLE RDBMS Version 6.0 with the transaction processing 
option, use ALWAYS for this parameter to acquire row locks when a 
table is updated. 

For ORACLE RDBMS Version 6.0 without the transaction processing 
option, use INTENT for this parameter to use row locks on a SELECT 

FOR UPDATE. Table locks are used in other cases. 

If you have the transaction processing option, DEFAULT means 

ALWAYS. If you do not have the transaction processing option, 
DEFAULT means INTENT. 

Default 

DEFAULT 

Range of Values 

DEFAULT/ALWAYS/INTENT 

When to Change 

When you need to use table-level or row-level locking. 

Effects of Change 

ALWAYS locks rows. INTENT locks tables when an UPDATE, 

INSERT, or DELETE is done. 

Reference 

’Tuning SQL Statements and Applications", Chapter 2; SERIALIZABLE. 
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SEQUENCE_CACHE 

Description 


Default 
Range of Values 
When to Change 

Effects of Change 

Reference 


ENTRIES 

Sets the number of sequence definition entries that can be held in the 
SGA. Each entry in the cache holds a single sequence, and you need 
one cache entry for every SEQUENCE in use concurrently. Be sure the 
SEQUENCE cache is large enough to accommodate all the sequences 
used simultaneously by your database applications. 

If the value for the SEQUENCE_CACHE_ENTRIES is too low, more 
I/O will occur. 

Note that the sequence definition cache is different from the 
CACHE/NOCACHE option of the CREATE SEQUENCE statement. 
The INIT.ORA parameter defines how many sequence definitions can 
be cached. The CREATE SEQUENCE CACHE statement defines how 
many numbers for a cached sequence will be used before going back to 
disk to allocate the next number. 

Sequences that are created with the CREATE SEQUENCE NOCACHE 
statement do not reside in the sequence definition cache, as such 
sequences have to be written through to the dictionary on every use. 

You may want to change the value of this parameter from its default on 
installation of ORACLE Version 6. A description of this appears in 
Appendix A. 

10 sequence definitions 

10 to 32,000 

If all applications running on the database use more than 10 different 
sequence numbers. 

Highest concurrency is achieved when this value is set to the highest 
number of sequences that will be used on an instance at a time. 

"Changing the Value of INIT.ORA Parameters" in Appendix A; Chapter 
5 of the ORACLE RDBMS Database Administrator's Guide. 
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SERIALIZABLE 


Description 

In conjunction with the parameter ROWJLOCKING, this parameter 
determines locking behavior. When SERIALIZABLE is TRUE, queries 
acquire table-level read locks, preventing updates until the transaction 
containing the query is committed. This mode of operation provides 
repeatable reads and ensures that two queries for the same data within 
the same transaction see the same values. 

Default 

For ORACLE RDBMS Version 6 with the transaction processing option, 
the default for SERIALIZABLE is FALSE, to maximize concurrency. 

Range of Values 

FALSE/TRUE 

When to Change 

When repeatable reads are required, change this parameter to TRUE 
and ROW_LOCKING to INTENT. 

Effects of Change 

Locks tables instead of rows, and serializes update access. 

Reference 

’Tuning SQL Statements and Applications", Chapter 2; 

ROW LOCKING. 
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SORT_AREA_SIZE 

Description The size in bytes of memory expected to be available for sorting. You 
may want to change the value of this parameter from its default on 
installation of ORACLE Version 6. A description of this appears in 
Appendix A. 

Default and Range of Operating system dependent 
Values 


When to Change If very large indexes are being created, and there is enough operating 

system memory to accommodate extra memory for sorting, or if queries 
that sort large numbers of rows are sorted (GROUP BY DISTINCT and 
ORDER), then increasing this parameter will improve performance. 


Effects of Change Reduces the number of intermediate runs that are produced before the 
final result of the sort, and thus the amount of I/O necessary to 
complete the sort. As a rule, a larger size improves the efficiency of 
large sorts. This parameter affects the sort area size for all processes; it 
could cause excessive memory use if set too high. 


Reference 


The section 'Tuning Sorts" in Chapter 6; "Initial RDBMS Installation 
Guidelines," Appendix A. 
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SORT_SPACEMAP_SIZE 

Description The size in bytes of the sort spacemap in the context area. This 



parameter aids ORACLE in managing the spacemap for intermediate 
sorts. 

Default 

Operating system dependent 

When to Change 

Do not change this parameter. 

Reference 

The section, "Tuning Sorts" in Chapter 6; "Initial RDBMS Installation 
Guidelines," Appendix A. 

SQL_TRACE 


Description 

Enables the SQL trace facility with the ALTER SESSION command. 
This parameter provides information on tuning which you can use to 
improve performance. 

Default 

FALSE 

Range of Values 

FALSE/TRUE 

When to Change 

When tracing is desired. 

Effects of Change 

Causes system overhead for the trace when set to TRUE. Thus, you 
should run the database with the value TRUE only for the purposes of 
collecting these statistics. 

Reference 

TIMED_ST ATISTICS, MAX_DUMP_FILE_SIZE, USER_DUMP_DEST; 
The section on "Setting INIT.ORA Parameters for the SQL Trace 
Facility" in Chapter 7. 
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TIMED_STATISTICS 

Description Enables timing of system functions for the SQL trace facility (e.g., CPU 
and elapsed times) and for certain SQL*DBA MONITOR screens. 

Default FALSE 


Range of Values 
When to Change 
Effects of Change 
Reference 


USER_DUMP_DEST 

Description 

Default 
Range of Values 
When to Change 
Effects of Change 
Reference 


FALSE/TRUE 

When you want to turn on or off timing statistics. 

TRUE turns on timing. System overhead increases during timing. 

SQL_TRACE; The section ’’Setting INIT.ORA Parameters for the SQL 
Trace Facility" in Chapter 7. 


Specifies the directory in which trace files for user processes are 
written. This parameter can be used to direct the output of the SQL 
trace facility. 

Operating system dependent 
Operating system dependent 

When you want to write your dump files to another directory. 
Routes dump files to specified directory. 

Your Installation and User's Guide; The section on "Setting INIT.ORA 
Parameters for the SQL Trace Facility" in Chapter 7. 
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DC_COLUMNS 3-11, A-2, C-5 
DC_CONSTRAINT_DEFS C-5 
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of CREATE TABLESPACE statement 4-14 
example 4-14 
Design 

of data 2-4 
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See Data dictionary 
Dirty buffers B-2 
Dirty list B-2 
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Distributing I/O 1-5,4-4, 4-6 to 4-7, A-5 
Dynamic performance tables 
V$ROWCACHE table 3-13 
V$WAITSTAT table 5-5,6-8 

E 
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of ALTER USER statement 6-2 
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2-20 to 2-21 
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4-14 
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4-6 to 4-7, 4-14 
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of execution plan 2-6, 2-13 to 2-14, 2-25 
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of indexed query 2-7, 2-12, 2-14 
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of LOCK TABLE statement 2-15 

of non-clustered join 2-24 

of NOSORT option 6-4 
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of space management in a data block 4-10 
of SQL trace facility output 2-13 to 2-14, 2-25, 
7-7 

of STORAGE clause 4-6, 4-14 
of table "striping” 4-6 
of TABLESPACE clause 4-6 to 4-7 
of TEMPORARY TABLESPACE clause 6-2 
Execution plan 2-3, 2-5, 7-9 

example 2-6, 2-13 to 2-14, 2-25, 7-7 
EXPLAIN PLAN statement 2-3, 7-9 
example of output 2-6, 2-25, 7-7 
invoking with the TKPROF program 7-6 
output table PLAN_TABLE 7-9 
syntax for invoking 7-10 
Export 

See Import and Export utilities 
Extension 

generates recursive calls 4-15 
of segments 4-15 
Extents 4-13 
number of 4-13 
size of 4-13 

F 

Free buffers B-2 
Free lists 4-9 to 4-10, 6-5 
adding more 6-9 
contention for 6-5 to 6-6 
number of 6-5 
reducing contention 6-9 
Free space 4-8,4-10 
choosing limits for 4-11 
FREE_LIST_INST C-12 
FREE_LIST_PROC 4-9, 6-5, 6-9, A-3, C-13 
Full table scan 2-8 
example 2-6, 2-13 
free space and 4-11 
indexed queries vs. full table scans 2-8 

with multi-block read 2-9 

on small tables 2-10 
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GETMISSES column 

of V$ROWCACHE table 3-13, 3-15 to 3-16 
GETS column 

of V$ROWCACHE table 3-13,3-15 to 3-16 
GRANT statement 
example 2-20 
Group functions 
MAX 2-9 
MIN 2-9 

H 

Hit Ratio statistic 3-18 to 3-19, 3-23 
calculating 3-24 
HOLD_CURSOR 3-9 

I 

I/O 

distributing 1-5, 4-4, 4-6 to 4-7, A-5 
ID column 

of PLAN.TABLE table 7-11 
Import and Export utilities 
using array processing 2-28 
BUFFER keyword 2-29 
Index segments 4-12 
Indexes 1-4, 2-7 

choosing columns for 2-9 
cluster 2-22 
concatenated 2-10 
example 2-7,2-12, 2-14 
use with group functions MAX and MIN 2-9 
indexed queries vs. full table scans 2-8 
modifying values of 2-10 
performance benefits 2-8 
placement on disk 4-7 
selectivity 2-9 
unique 2-8 to 2-9 
use with WHERE clauses 2-9 
See also Concatenated indexes 
INDX column 

of X$KCBCBH table 3-23 
of X$KCBRBH table 3-20 


INIT.ORA parameters 

changing upon installation A3 
CONTEXT_AREA 3-8, C-2 
CONTEXTJNCR 3-8, C-3 
CPU_COUNT 5-11,5-13, C-4 
DB_BLOCK_BUFFERS 3-17, 3-19, 3-23, A-2, 
B-2, C-8 

DB_BLOCK_LRU_EXTENDED_STATISTICS 
3-20, C-9 

DB_BLOCK_LRU_STATISTICS 3-23, C-9 
DB_BLOCK_MAX_SCAN_CNT B-2 to B-5, 
C-10 

DB_BLOCK_SIZE 4-8,4-13, C-10 
DB_BLOCK_WRITE_BATCH B-4 to B-5, C-ll 
DB_FILE_MULTIBLOCK_READ_COUNT 
2-9, C-12 

DC_COLUMN_GRANTS C-5 
DC_COLUMNS 3-11, A-2, C-5 
DC_CONSTRAINT_DEFS C-5 
DC_CONSTRAINTS C-5 
DC_FILES C-5 
DC_FREE_EXTENTS C-6 
DCJNDEXES C-6 
DC.OBJECTJDS C-6 
DCJDBJECTS C-6 

dc_rollback_segments C-6 

DCSEGMENTS C-6 
DC_SEQUENCE_GRANTS C-6 
DC_SEQUENCES C-6 
DC_SVNONYMS C-6 
DC_TABLE_GRANTS C-6 
DC_TABLES A-2, C-7 
DC_TABLESPACE_QUOTAS C-7 
DC_TABLESPACES C-7 
DC_USED_EXTENTS C-7 
DC_USERNAMES C-7 
DC_USERS C-7 
FREE_LIST_INST C-12 
FREE_LIST_PROC 6-5, 6-9, A-3, C-13 
LOG_ALLOCATION A-3,C-14 
LOG_BUFFER C-15 
LOG_CHECKPOINT_INTERVAL 
6-11 to 6-12, C-15 

LOG_ENTRY_PREBUILD_THRESHOLD 
5-13, C-16 
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LOG_SIMULTANEOUS_COPIES 5-11,5-13, 
C-16 

LOG_SMALL_ENTRY_MAX_SIZE 5-11,5-13, 
C-17 

MAX_DUMP_FILE_SIZE 7-3, C-18 
OPEN_CURSORS 3-8, 3-10, C-19 
PROCESSES A-3,C-19 
ROLLBACK_SEGMENTS A-3, C-20 
ROW.LOCKING 2-15, C-21 
SEQUENCE_CACHE_ENTRIES 2-21, A-3, 
C-22 

SERIALIZABLE 2-15, C-23 
SORT_AREA_SIZE 6-2 to 6-3, A-3, C-24 
SORT_SPACEMAP_SIZE 6-2, C-25 
SQL_TRACE 7-4, C-25 
TIMED_STATISTICS 7-3, C-26 
USER_DUMP_DEST 7-3, C-26 
INITIAL storage parameter 4-13 to 4-14 
Installation 

tuning recommendations for A-l 
Instance 

free list sets C-12 

J 

Joins 

example of clustered join 2-24 to 2-25 
example of non-clustered join 2-24 
optimizing with clusters 2-22 to 2-23 

K 

Key 2-7 

concatenated 2-11 

L 

Latches 

See Redo allocation latch 
See Redo copy latches 
Leading portion 

of a concatenated index 2-11 
examples 2-11 

Least-recently-used (LRU) list B-2 
LGWR 


See Log Writer process (LGWR) 

LOCK TABLE statement 
example 2-15 
Locks 

contention 2-15 to 2-16 
monitoring activity 2-16 
See also Row-level locking 
Log 

See Redo log 
Log switches 

causing checkpoints 6-10, 6-12 
Log Writer process (LGWR) 

behavior on checkpoints 6-11, B-4 
redo log buffer management 5-9 
tuning 4-5 

writing the redo log buffer to redo log files 
5-9 

LOG.ALLOCATION A-3, C-14 
LOG_BUFFER C-15 

LOG_CHECKPOINT_INTERVAL 6-11 to 6-12 
LOG_ENTRY_PREBUILD_THRESHOLD 
5-13, C-16 

LOG_SIMULTANEOUS_COPIES 5-11, 5-13, 
C-16 

LOG_SMALL_ENTRY_MAX_SIZE 5-n, 5-13, 
C-17 

Logical Reads statistic 3-18,3-21, 3-24 
LRU list 

See Least-recently-used (LRU) list 

M 

MAX group function 
using an index 2-9 
MAX_DUMP_FILE_SIZE 7-3, C-18 
MAXEXTENTS storage parameter 4-13 
MAXOPENCURSORS 3-9 
Memory allocation 

for context areas 3-8, 3-10 
for data dictionary cache 3-11 
importance of 3-2 
for sort areas 6-2 to 6-3 
tuning 3-2, 3-26 
for users 3-7 
MIN group function 
using an index 2-9 
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MINEXTENTS storage parameter 4-15 
MINEXTENTS storage parameters 4-13 
Multi-block reads 2-9, 4-16 
Multi-block writes B-4 

N 

NEXT storage parameter 4-13 to 4-14 
NEXTVAL 

sequence pseudo-column 2-20 
NOCACHE option 

of CREATE SEQUENCE statement 2-22 
Normalization 2-5 
NOSORT option 6-4 

choosing when to use 6-4 
of CREATE INDEX statement 6-4 
example 6-4 
performance benefits 6-4 

o 

OBJECTJNSTANCE column 
of PLAN_TABLE table 7-11 
OBJECT_NAME column 
of PLAN_TABLE table 7-11 
OBJECT_NODE column 
of PLAN_TABLE table 7-11 
OBJECT_OWNER column 
of PLAN_TABLE table 7-11 
OBJECT TYPE column 

of PLAN_TABLE table 7-11 
OEFN call 2-27 
OEXN call 2-27 

Online transaction processing (OLTP) 
applications 2-15, A-5 
OPEN_CURSORS 3-8, 3-10, C-19 
Operating system tuning 3-6 
OPERATION column 

of PLANTABLE table 7-11 
of V$WAITSTAT table 5-5, 6-8 
values for 7-12 
Optimization 
example 2-6 

of joins with clusters 2-22 
of joins with clusters 2-23 


of queries with indexes 2-8 
of SQL statements 2-5 
Optimizer 

See ORACLE optimizer 
OPTIONS column 

of PLAN_TABLE table 7-11 
values for 7-13 

ORACLE Call Interfaces (OCIs) 
use of array processing 2-27 
control of parsing and context areas 3-9 
ORACLE optimizer 2-5 
ORACLE Precompilers 

use of array processing 2-27 
control of parsing and context areas 3-9 
use of PL/SQL 2-19 
OTHER column 

of PLAN_TABLE table 7-12 

P 

Paging 3-6, 3-10, 3-26 
PARAMETER column 

of V$ROWCACHE table 3-13, 3-15 to 3-16 
PARENTID column 

of PLAN_TABLE table 7-12 
Parsing 3-7 

and context areas 3-8, 3-10 
with the ORACLE Call Interfaces (OCIs) 3-9 
with the ORACLE Precompilers 3-9 
reducing 1-4, 3-9 
with SQL*Forms 3-10 
unnecessary 3-8 
PCTFREE 4-9 to 4-10 
choosing 4-11 

PCTINCREASE storage parameter 
4-13 to 4-14 
PCTUSED 4-9 to 4-10 
choosing 4-11 
phys column 

of SQL trace facility output 2-12, 2-14, 2-25, 
7-8 

Physical Reads statistic 3-18, 3-21, 3-24 
Pinned buffers B-2 
PL/SQL 2-16 

use with the ORACLE Precompilers 2-19 
performance benefits 2-17 
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PL/SQL blocks 2-16 
PL/SQL engine 2-17 
use with SQL*Forms 2-19 
use with SQL*Plus 2-19 
PLANTABLE table 
ID column 7-11 

OBJECTJNSTANCE column 7-11 
OBJECT_NAME column 7-11 
OBJECT_NODE column 7-11 
OBJECT_OWNER column 7-11 
OBJECT_TYPE column 7-11 
OPERATION column 7-11 
OPTIONS column 7-11 
OTHER column 7-12 
PARENT_ID column 7-12 
POSITION column 7-12 
REMARKS column 7-11 
SEARCH_COLUMNS column 7-11 
STATEMENT_ID column 7-11 
structure 7-10 
TIMESTAMP column 7-11 
POSITION column 

of PLAN.TABLE table 7-12 
"Pre-building" redo entries 5-13 
Process priority 1-5, 5-14 
PROCESSES A-3, C-19 

Q 

Queries 5-8 
Quotas 

and unlimited RESOURCE privilege C-7 

R 

RANGE column 

of V$WAITSTAT table 5-5 
Recovery from instance failure 
effect of checkpoints 6-12 
by rolling forward 6-10 
Recursive calls 3-12, 4-15 

and data dictionary cache misses 3-12 
detected by the SQL trace facility 7-8 
and dynamic extension 4-15 
recursive calls statistic 3-12, 4-15 


Redo allocation latch 5-11 
"copying on" 5-11 
contention for 1-5, 5-13 
redo chunk allocations statistic C-14 
Redo copy latches 5-11 

choosing how many 5-11, 5-13 
contention for 1-5, 5-13 
creating more 5-13 
Redo entries 5-9 
"pre-building" 5-13 
purpose of 5-9 
Redo log buffer 5-9 
writing to 5-9 
Redo log files 

increasing the size of 6-12 
placement on disk 4-5 
writing to 5-9 

redo log space requests statistic 5-10, C-15 
Relational theory 2-5 
RELE ASE_CURSOR 3-9 
REMARKS column 

of PLAN_TABLE table 7-11 
Request Rate Read/s statistic 4-3 
Request Rate Write/s statistic 4-3 
Rollback entry 5-2 
Rollback segments 4-12, 5-2 
choosing how many 5-7, A-4 
choosing sizes for 5-7, A-4 
contention for 5-3 
creating 5-7 
creating size of 5-7 
purposes of 5-2 
reducing contention for 5-7 
ROLLBACK_SEGMENTS A-3, C-20 
Rolling forward 
for recovery 6-10 
Row-level locking 1-4, 2-14 
establishing as default 2-15 
performance benefits 2-15 
row-level locking vs. table-level locking 2-15 
taking advantage of 2-15 
ROW_LOCKING 2-15, C-21 
ROWID 2-8 

example of searching by 2-14 
Rows 

number processed 2-28 
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of SQL*Loader command 2-28 

ms column 

of SQL trace facility output 7-8 


s 

SEARCH_COLUMN column 
of PLAN_TABLE table 7-11 
Segments 4-12 
extension of 4-15 
Selectivity 

of concatenated indexes 2-10 
of indexes 2-9 
of unique indexes 2-9 
SEQUENCE_CACHE_ENTRIES 2-21, A-3, 
C-22 

Sequences 1-4, 2-19 
application uses 2-19 
caching sequence numbers 2-21 
example 2-20 

pseudo-column CURRVAL 2-20 
pseudo-column NEXTVAL 2-20 
reducing serialization 2-19 
SERIALIZABLE 2-15, C-23 
Serialization 2-19 
SGA 

See System Global Area (SGA) 

SIZE parameter 

of CREATE CLUSTER statement 2-24 
Sort areas 6-2 

memory allocation 6-2 to 6-3 
size 6-2 

SORT_AREA_SIZE 6-2 to 6-3, A-3, C-24 
SORT_SPACEMAP_SIZE 6-2, C-25 

Sorts 

avoiding on index creation 6-4 
causes 6-2 
tuning 6-2 
Space management 
in clusters 2-24 
example 4-10 
for full table scans 4-11 
in data blocks 4-8 
for varying length rows 4-11 


SQL statements 


causing sorts 6-2 

changing free space in data blocks 4-8 
modifying indexed data 2-10 
optimization of 2-5 
parsing of 3-7 to 3-8 
tuning 2-2 to 2-3 
SQL trace facility 2-3, 3-8, 7-2 
enabling 7-3 to 7-4 

example of output 2-13 to 2-14, 2-25, 7-7 

steps to follow 7-2 

See also TKPROF program 

trace files 7-3 to 7-4 


count column 7-7 
cpu column 2-12, 2-14, 2-25 
cr column 7-8 
cur column 7-8 

elap column 2-12, 2-14, 2-25, 7-8 
example 2-13, 2-25 
phys column 2-12, 2-14, 2-25, 7-8 
rows column 7-8 


SQL*DBA , „„ 

enabling statistics for MONITOR displays 7-3 
MONITOR displays 7-1 
MONITOR FILE I/O display 4-3 to 4-4, 4-7, 


6-3 

MONITOR I/O display 3-18 
MONITOR LATCH display 5-12 
MONITOR LOCK display 2-16 
MONITOR STATISTICS CACHE display 
5-3 to 5-4, 6-6 to 6-7, B-5 to B-6 
MONITOR STATISTICS REDO display 5-10 
MONITOR STATISTICS USER display 3-12, 
4-15 

SHOW PARAMETERS command C-2 
SHOW SGA command 3-3 
SQL*Forms 7-3 

use of array processing 2-27 
control of parsing and context areas 3-10 
use of PL/SQL 2-19 
Version 3.0 2-17 
SQL*Loader 

using array processing 2-28 
command line argument ROWS 2-28 
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SQL*Plus 2-17 

use of array processing 2-28 
COPY command 2-28 
use of PL/SQL 2-19 
SET ARRAYSLZE command 2-28 
SHOW ARRAYSIZE command 2-28 
system variable ARRAYSIZE 2-28 
SQL_TRACE 7-4, C-25 
Startup 

examining recursive calls after 3-12 
STATEMENT.® column 
of PLAN_TABLE table 7-11 
Statistics 

Batch Size blks/W 4-3 
buffer busy waits 5-3 to 5 - 4 , 5-7, 6-6 to 6-7 
consistent gets 5-3 to 5-4, 6-6 to 6-7 
db block gets 5-3 to 54, 6-6 to 6-7 
dbwr checkpoints C-15 
dbivr free low B-5 to B-6 
dbwr free needed B-5 to B-6 
enabling collection of 3-20 
Hit Ratio 3-18 to 3-19, 3-23 
Logical Reads 3-18,3-24 
Physical Reads 3-18,3-24 
recursive calls 3-12,4-15 
redo chunk allocations C-14 
redo log space requests 5-10, C-15 
Request Rate Read/s 4-3 
Request Rate Write/s 4-3 
Timeout Willing to Wait Requests 5-12 
Total Willing to Wait Requests 5-12 
write complete waits C-l 1 
write wait time C-ll 
STORAGE clause 

of CREATE TABLE statement 4-6, 4-14 
example 4-6,4-14 
Storage parameters 4-13 
INITIAL 4-13 to 4-14 
MAXEXTENTS 4-13 


MINEXTENTS 4-13,4-15 
NEXT 4-13 to 4-14 
PCTINCREASE 4-13 to 4-14 
"Striping" tables 4-6 
System Global Area 
example 4-6 
Swapping 3-6,3-10,3-26 


System Global Area (SGA) 1-5, 3-3, 3-6 
SHOW SGA Command 3-5 


T 

Table "striping" 
example 4-6 
Tables 

placement on disk 4-7 
TABLESPACE clause 

of CREATE TABLE statement 4-6 to 4-7 
example 4-6 to 4-7 
temporary segments 4-12 
TEMPORARY TABLESPACE clause 
of ALTER USER statement 6-2 
example 6-2 
TIME column 

of VSWAITSTAT table 5-6 
TIMED_STATISTICS 7-3, C-26 
Timeout 

invoking DBWR B-4 

Timeout Willing to Wait Requests statistic 
5-12 

TIMESTAMP column 

of PLANJTABLE table 7-11 
TKPROF program 7-2, 7-4 
arguments 7-4 
example of output 7-7 
invoking the EXPLAIN PLAN statement 
with 7-6 

syntax for invoking 7-4 
Total Willing to Wait Requests statistic 5-12 
Trace facility 

See SQL trace facility 
Transaction processing option 
default locking behavior 2-15 
PL/SQL incorporated with 2-17 
row-level locking 2-14 
Tuning 

applications 1-3,2-2 to 2-3 

buffer cache 3-17 

checkpoints 6-10 

contention 1-4, 5-1 

data dictionary cache 3-11 

Database Writer process (DBWR) B-7 

I/O 1-3 
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memory allocation 1-3, 3-2, 3-26 
method tor 1-2 

operating system d-6 

siting for 1-2 

suns o-i 

SQL statements 1-3, 2-2 to 2-3 

***•< -f* Cv-» % \ 

U 

Undo segment header 
See Rollback segment 
Unique indexes 2-8 
selectivity 2-9 
USAGE column 

of V$ROWCACHE table 3-13,3-15 to 3-16 
USER_DUMP_DEST 7-3, C-26 

V 

V$ROWCACHE table 3-13 

COUNT column 3-13,3-15 to 3-16 

data dictionary cache performance statistics 

3-13 

GETMISSES column 3-13, 3-15 to 3-16 
GETS column 3-13, 3-15 to 3-16 
PARAMETER column 3-13, 3-15 to 3-16 
USAGE column 3-13, 3-15 to 3-16 
VSWAITSTAT table 5-5 
CLASS column 5-5, 6-8 
COUNT column 5-6, 6-8 
data block contention statistics 5-5 
free list contention statistics 6-8 
OPERATION column 5-5, 6-8 
RANGE column 5-5 

rollback segment contention statistics 5-5 
TIME column 5-6 
Virtual tables 

X$KCBCBH table 3-23 
X$KCBRBH table 3-20 


w 


X 

X$KCBCBH table 

buffer cache performance statistics 3-23 
COUNT column 3-23 
enabling use of 3-23 
ThfDX column 3-23 
X$KCBRBH table 

buffer cache performance statistics 3-20 
COUNT column 3-20 
enabling use of 3-20 
INDX column 3-20 
XPLAINPL.SQL 7-9 


write complete waits statistic C-ll 
write wait time statistic C-l 1 
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Reader’s Comment Form 

ORACLE RDBMS Performance Tuning Guide 

Part No. 5317-V6.0 

August 1989 (Revised February 1990) 

Oracle Corporation welcomes your comments and suggestions on the quality and usefulness of this 
publication. Your input is an important part of the information used for revision. 

• Did you find any errors? 

• Is the information clearly presented? 

• Do you need more information? If so, where? 

• Are the examples correct? Do you need more examples? 

• What features did you like most about this manual? 

If you find any errors or have any suggestions for improvement, please indicate the topic, chapter, 
and page number below: 


Please send your comments to: 

ORACLE RDBMS Product Manager 
Oracle Corporation 
500 Oracle Parkway 
Redwood Shores, CA 94065 
(415) 506-7000 


If you would like a reply, please give your name, address, and telephone number below: 


Thank you for helping us improve our documentation. 
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